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

Doug replied on 06/04/2004 11:50:57 AM:
> > > 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. 
> 
> I think it is a very much needed feature. Have you looked at all of the 
> custom X- properties
> and specific sub-sets of iTIP objects that are coming back? As I learn 
> them I add the
> ability for the CUA to use them, or translate their features at run time 

> into CAP properties
> or x- properties that I use, when they overlap. Just check out how 
> people define
> time zones with special property names as one example.

It may be useful for doing a "find me all properties and subcomponents 
that exist in this container" but I strongly doubt that its something done 
on a regular basis.  It can be useful for debugging or protoyping purposes 
but not for normal CU day to day actions.

Besides why do you care if if appears _anywhere_ in _any _ component when 
those properties will _always_ be returned as part of the normal "Give me 
this VEVENT" SEARCH:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: TARGET:BrucesRelCal
   C: CMD:SEARCH
   C: BEGIN:VQUERY
   C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = '[email protected]'
   C: END:VQUERY
   C: END:VCALENDAR

would result in:

   S: BEGIN:VCALENDAR
   S: TARGET:BrucesRelCal
   S: CMD:REPLY
   S: BEGIN:VREPLY
   S: BEGIN:VEVENT
   S: DTSTART;TZID="Eastern":20040602T090000
   S: DTEND;TZID="Eastern":20040602T130000
   S: TRANSP:TRANSPARENT
   S: DTSTAMP:20040604T181825Z
   S: CLASS:PRIVATE
   S: DESCRIPTION:Join us on Wednesday June 2nd for a presentation 
   S:  and  watch the new Shrek 2 movie! 
   S: SUMMARY:Demo Seminar and Movie
   S: LOCATION:AMC Burlington 10
   S: ORGANIZER;CN="Bruce Kahn":mailto:[email protected]
   S: UID:[email protected]
   S: X-Hinkey-Minkey:Some special value
   S: END:VEVENT
   S: END:VREPLY
   S: END:VCALENDAR

The CUA is going to get _all_ the properties in the VEVENT so again I 
think this is only beneficial to developers who want to be able to do some 
form of data scanning; not that they can _interpret_ the results, just 
they can _see_ it.

So again Ill ask what real benefit is there to the CU in being able to do 
a "give me all the properties that appear in an VEVENT in the calendar in 
a mush" dump on any kind of basis?  I seriously doubt its useful to the 
end CU; it sounds more like something useful to developers only and only 
for occasional use even then.   However even this kind of dump can be 
achieved thru other means that are just as simple (SELECT * FROM VEVENT) 
so again _what_ is the benefit in having the component.* in the query 
language??

Looking at it from a slightly different perspective, the only noticable 
difference between:

SELECT VEVENT.* FROM VAGENDA

and

SELECT VEVENT FROM VAGENDA

is just the 22 octets that make up the BEGIN:VEVENT / END:VEVENT wrappers 
of each VEVENT that would be returned.  Well, that and the fact that the 
data from the former case is not actionable by the CUA but the data from 
the latter case actually is.  So where is there any real benefit??

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