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

Doug responded on 06/11/2004 01:40:31 PM:
> > 1: Component integrity is not always preserved.
> 
> 
> So you say. EXACTLY HOW?

Go reread my previous posts in this thread for citations and examples.  I 
wont repeat them here ad infinitum.

> >  There has been no justification given for the component-name.* use in 

> > the SELECT clause.  It results in data that is all mushed togther and 
> > not useable as returned.
> > 2: There are "special cases" in CAP that result in different formats 
> > returning the same data.  So far there has been no reason given for 
> > why we need the special cases really. 
> 
> Simply not true.

Actually it is true.  I have based all my points on actual CAP text and 
included relevant citations.  Please feel free to go and check them for 
accuracy and make corrections if I missed something.

Please show us how removing the BEGIN/END markers so that all properties 
and subcontainer properties are mixed together in an unusable is _not_ 
true?  One only has to try an actual example to see how useless this is. 

Try a VEVENT with 3 VALARMs: a display, an email and an audio alarm.  The 
VALARM ATTENDEE, ATTACH, DURATION, DESCRIPTION and SUMMARY properties of 
each VALARM will be freely mixed in with each others and those of the 
VEVENT making them inseparable in any meaningful way.  I am now strongly 
inclined to believe that this "component.*" concept is residual from the 
original SQL query modeling and serves no productive purpose in CAP-QL.

Please show us where in CAP it actually defines "*" in the SELECT clause 
as meaning "all properties and subcontainers" or "all properties and no 
subcontainers".

Please show us where in Section 6.1.1 where it gives an special meaning to 
"*" on VAGENDAs and VCALSTOREs thats different from other containers.

Now that I reread 6.1.1 in greater detal, please show how bullet item 4 in 
Section 6.1.1 does NOT actually prohibit querying for subcomponents?  That 
is, "SELECT DTSTART,DTEND,VALARM FROM VEVENT WHERE UID = '[email protected]'" 
is illegal by:

   4.  Everything in the "SELECT" clause and "WHERE" clauses in MUST BE
       from the same component type, or "VAGENDA" component OR
       "VCALSTORE" component in the "FROM" clause.
 
My proposal is intended to fix up all these ambiguities and unspecified 
things so that query behaviour is clear and consistant for all containers. 
 (Actually I just noticed that bullet #4 bit now and didnt address it but 
I think we should...)

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