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

[email protected] Fri, 4 Jun 2004 10:44:18 -0400
Newsgroups gmane.ietf.calendar
Message-ID <OF1CA70F88.D7019139-ON85256EA9.004D56BB-85256EA9.0050CACB@notesdev.ibm.com>
Doug replied on 06/03/2004 06:26:20 PM:
> > Out of curiosity, can anyone describe a case when you would want this 
> > (VEVENT.* or VALARM.*) as opposed to no ".*"?
> 
> Please read the rest of my reply - where I did.

I did read your entire post and I took it to be more a tongue in cheek 
example rather than a pratical usage example.  Sorry if my follow up wasnt 
that clear.  From the previous reply:

> It answers the quetion, what property names are in any VEVENTs in my 
> calendar.
> If that is usful :-)

It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey on 
any VEVENT in my calendar?" but I dont think thats a common need really or 
even necessary actually given most queries would just use "*" or can list 
any desired properties on the SELECT and then see what comes back. 

Put another way: Why should I care if it exists on any entry anywhere in 
the calendar when I can easily tell by simply looking for it on any VEVENT 
when I retrieve it normally?  Knowing it exists on a component _somewhere_ 
in the calendar is not that useful as it does not tell me on which one(s) 
and if I needed to just see those kinds of entries I simply use that as 
part of my WHERE clause to begin with...  (SELECT * FROM VEVENT WHERE 
X-HINKEY-MINKEY IS NOT NULL)

Given most queries would typically be of the form:

        SELECT * FROM VEVENT WHERE UID = "123"

to get a specific VEVENT or like:

        SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED'

to get unprocessed requests, is there any _practical_ use for VALARM.* or 
VEVENT.* that Im just not groking?? 

BTW: The "This does not fetch any components" part above is inaccurate. It 
actually fetches them ALL but combines them into one long massive stream 
of data.  There has been nothing said about 'unwrappering' sub-components 
like VALARMs so I would expect them to be still wrappered in the 
amalgamated stream of VEVENT (and VTODO and VJOURNAL and VTIMEZONE and 
VQUERY and ... ) mush.

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