RE: list of items (recur-id is not CAP)

> -----Original Message-----
> From: Doug Royer [mailto:[email protected]]
> Sent: Monday, November 24, 2003 4:03 PM
> To: [email protected]
> Subject: Re: list of items (recur-id is not CAP)
> 
> 
> 
> 
> Arnaud Quillaud wrote:
> 
> >Actually, if I understand it correctly, the following section of CAP
> >seems to make use of the "wrong" model for recurrence-id:
> ><<
> >6.1.1.15 Query by Date-Time range
> >
> >   This query selects the entire content of every booked "VEVENT"
> >   component that has an instance greater than or equal to July 1st,
> >   2000 00:00:00 UTC and less than or equal to July 30st, 
> 2000 23:59:59
> >   UTC. This includes single instance "VEVENT" components that do no
> >   explicitly contain any recurrence properties or "RECURRENCE-ID"
> >   properties. This works only for CSs that have the "RECUR-EXPAND"
> >   property value set to "TRUE" in the "GET-CAPABILITY" exchange.
> >
> >   BEGIN:VQUERY
> >   EXPAND:TRUE
> >   QUERY:SELECT * FROM VEVENT
> >   WHERE RECURRENCE-ID >= '20000701T000000Z'
> >   AND RECURRENCE-ID <= '20000730T235959Z'
> >   AND STATE() = 'BOOKED'
> >   END:VQUERY
> >  
> >
> >Since the recurrence-id of an instance might not correspond to its
> >current dtstart, the example above won't do what its 
> description says it
> >should do.
> >Why can't we use the DTSTART for this type of query ?
> >
> If you sent:
> 
>     QUERY:SELECT * FROM VEVENT
>       WHERE DTSTART >='20000701T000000Z'
>        AND DTSTART <='20000730T235959Z'
> 
> You would get back VEVENTs with a DTSTART property value between
> those two dates. If a recurring VEVENT existed and was daily starting
> from DTSTART:19990101T000000Z, it  would not match the query, even
> when one of its instances (RECURRENCE-ID) did match. The same is

Why ? Each of the instances of a recurring event has a DTSTART as far as I know.
Why would we take into account only the first instance ?

> true if the VEVENT had a RDATE:20000702T000000Z, as you did not
> query for RDATE, it would not match as RDATE is not DTSTART.
> 
> The DTSTART value only matches the RECURRENCE-ID on the first instance
> of a repeating object. If you query for DTSTART values, that 
> is what you 
> will get.
> If you query for RECURRENCE-ID values, then you get any VEVENT that
> has an effective instance start time that matches that value 
> (somehow stored
> or computed).

That is true only if the RECURRENCE-ID of the instance matches the DTSTART of this instance.
If this instance was originally:
 
RECURRENCE-ID:20000729T000000Z
DTSTART:20000729T000000Z

 but the DTSTART is moved to 20000802T000000Z

we end up with

RECURRENCE-ID:20000729T000000Z
DTSTART:20000802T000000Z

If the "Query by Date-Time range" in the CAP example is done using the RECURRENCE-ID, this particular instance will be returned when it actually doesn't belong to that range.

> 
> All objects with an RRULE or RDATE property values have virtual
> RECURRENCE-ID's even when an RECURRENCE-ID was
> not explicitly sent or stored in the object.
> 
> What do you think you would get back if EXPAND:FALSE were in
> the CAP example?

My understanding is that we would return any event object that has at least one instance that matches the filter (whether it is RECURRENCE-ID or DTSTART).
So for recurring event, we would return the MASTER event (the one containing RRULE/RDATE) and all its exceptions if there are any.

If we take a daily VEVENT starting  from DTSTART:19990101T000000Z and recurring forever, it would be a match even though the DTSTART of this master event is not in the range.
So we would get back:

BEGIN:VEVENT
DTSTART:19990101T000000Z
RRULE:FREQ=DAILY
...

But that is far from being obvious. After reading the CAP spec, I should say that I don't know.

Arnaud