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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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 = '12345@xxxxxxxx'
   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:Bruce_Kahn@xxxxxxxxxxxxxxxx
   S: UID:12345@xxxxxxxx
   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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...