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

Doug responded on 06/07/2004 05:39:49 PM:
> > > If the "component.*" concept was removed from 6.1.1, you can _still_
> > > get all your data from all the unknown sources you want.  It would
> > > just be a few octets longer AND all subcomponents would be fully
> > > parsable, separatable and usable.  How would that be bad?? 
> 
> You forgot embedded object are included in the other form. MUCH more 
> that 22 octets per object.

Please show me how I forgot embedded objects?  I fully took into account 
subcontainers and preserving their integrity when returning them so they 
would be intact and useable. 

When using component names in the SELECT clause, they are to be returned 
with wrappers intact. 

When using "SELECT *" and an INCLUDE clause, the specified subcontainers 
are returned with wrappers intact.

Nowhere in any current CAP text did it say that all wrappers for nested 
subcontainers are to be stripped away.  That is, nowhere does it say that:

        SELECT VEVENT.* FROM VAGENDA

would result in all VALARMs in all the VEVENTS would be returned without 
the BEGIN/END wrappers.  Go recheck bullet #7, it only talks about the 
given components wrappers.

> And again it works as documented, is it really worth rewriting simply 
> becuase you want
> it another way? What is your justification for wanting to change this at 

> this late date?

Im not sure if this is a case of miscommunication of the issues, 
personality conflict or the normal vendor desire to get something RFCd out 
so products can be shipped so Ill opt for the first one and try again.

There are ambiguities and questionable cases in the query language that I 
think should be resolved before we go to Last Call.  "Works as documented" 
does not address the ambiguities or justify seemingly useless aspects of 
the query language.

The core issues I have are simply put:

1: Component integrity is not always preserved.  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.

I want to have a query language thats clear, concise and unambiguious. 
That is why I made my proposal.  The changes are not that drastic as you 
would make it sound and I think they even simplify things.

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...
Warning: Dates in Calendar are closer than they appear.