Re: CAP 13: Bad CAL-QUERY example / description?

[email protected] Thu, 3 Jun 2004 14:51:12 -0400
Newsgroups gmane.ietf.calendar
Message-ID <OF9D7D0914.B41F2741-ON85256EA8.0065FF97-85256EA8.00676A95@notesdev.ibm.com>
Mike wrote on 06/03/2004 11:08:57 AM:
> Changed my mind.  I think it should be:
> 
>          (d) Selects every property and every component
>           that is in any "VEVENT" component, with each contained
>              component wrapped in BEGIN/END tags.
> 
> This whole section seems confusing to me though.  What query do I need 
to 
> get a list of all the BEGIN/END tagged VEVENTS in a VAGENDA?  SELECT 
> VEVENT FROM VAGENDA would seem right.

Actually that query would return to you all the VEVENTS and all their 
data, not a list of them.

>                                       What about without the BEGIN/END 
> tags?  SELECT VEVENT.* FROM VAGENDA sounds good. 

Hmm, thats the right query but it does point out something I was going to 
(You following me Mike??).  Doing that would effectively strip off all 
VEVENT 'wrappers' and blur all VEVENTs into 1 big stream.  Not very useful 
really since theres no way to separate them back out into separate 
VEVENTs.  The same concern applys to the (c) example in that same place:

       (c) SELECT VALARM.* FROM VEVENT

If there are multiple VALARMs on a single VEVENT then this would 
effectively strip away the BEGIN:VALARM/END:VALARM wrappers and mix those 
VALARM properties into the VEVENT properties.  There would be no way for a 
CUA to properly distinguish those VALARM properties from the VEVENT 
properties (had others been part of the SELECT clause) or to distingush 
the different VALARMs from each other.  Not a very useful thing to do in 
my mind. 

>                                                   But what's the 
> difference between that and SELECT * FROM VEVENT?

This query will NOT strip away the BEGING:VEVENT/END:VEVENT wrappers for 
each VEVENT.  The other query would.  Thats the difference.  The former is 
not desirable (at least not that I can picture).  The latter example is 
desirable because it allows distinct parsing of each VEVENT properly.

So I guess the question of usefulness arrises from this.  Whats the use of 
(c) if it has the undesirable effect of bleeding multiple VALARMs into 1 
big mush of properties?  (The same can be asked of Mikes SELECT VEVENT.* 
FROM VAGENDA example...)

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...