Subject: CAP: CALIDEXPAND and UPNEXPAND are they needed?

From: Patrice Lapierre <[email-masked]>
Date: Thu, 20 Sep 2001 18:57:58 -0400

Hi,

  In the cap draft it is not specified if the commands 
CALIDEXPAND and UPNEXPAND recursively expand the whole 
calendar hierarchy or only the immediate children. From 
a CUA perspective one level at a time seems the natural
behaviour.

  If that is the case, aren't the command CALIDEXPAND 
and UPNEXPAND redundant. It seems that similar results 
could be obtained by using a READ method combined with
 a VQUERY that performs a selection on respectively 
the PARENT and OWNER properties.

e.g. 
               C: CALIDEXPAND calid

Could be replaced by:   

               C: SENDDATA
               S: 2.0.1
               C: Content-type:text/calendar; Method=READ
               C: 
               C: BEGIN:VCALENDAR
               C: VERSION:2.1
               C: BEGIN:VCOMMAND
               C: METHOD:READ
               C: TARGET:calid
               C: BEGIN:VQUERY
               C: QUERY:SELECT RELCALID FROM VCALENDAR 
                    WHERE PARENT='calid'
               C: END:VQUERY
               C: END:VCOMMAND
               C: END:VCALENDAR
               C: .
        
They are some differences:

  1.The VQUERY returns RELCALID, CALIDEXPAND 
    returns CALID.
  2.Searching for top level calendars:
    CALIDEXPAND (and TARGET) can accept the CSID. 
    However PARENT only accept CALID, the absence of 
    the attribute is used to indicate a top level calendar.

  The first problem is probably not an issue (especially 
with fanout out of the picture). The second problem could
be resolved by either allowing PARENT to accept a CSID 
(making it more consistent to the TARGET property) or 
extending the SQL-MIN grammar to allow searches based on 
the absence of an attribute (e.g SELECT ... WHERE PARENT 
IS NULL).

  If UPNEXPAND and CALIDEXPAND can be subsumed by another 
command, then to avoid redundancies, I would recommend 
removing them from the draft.

Patrice.

---

From: George Babics <[email-masked]>
Date: Tue, 25 Sep 2001 10:52:11 -0400

If there are no objections I'll remove the commands.
They do seem redundant.

George