Re: CAP: CALIDEXPAND and UPNEXPAND are they needed?

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

George

Patrice Lapierre wrote:
> 
> 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.