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

[email protected] wrote:

>
> 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 practical usage example.  Sorry if my follow up 
> wasn't 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.  

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.

When getting a VCALEDNAR object back from a random source. The only way
to figure out which set of x- properties they use, is to scan for 
properties and figure it out.
I have generated several compliant VCALENDAR objects that crash popular 
CUAs.
So I translate them into what the CUA can handle. Try pointing several 
of the CUAs
that exist at a full featured CAP VCALENDAR object, I have been able to 
crash
all of the CUAs so far that I can find with various valid objects.

The real solution is more RFCs on how to do specific things, but for now 
they
all seem to be using valid (or nearly valid) iCal objects that are mostly
compatible with each other. At this point run time checking is the only 
way to determine
what you will be getting before trying to use the data.

--
Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards