[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.