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...