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

Doug wrote on 06/04/2004 04:24:16 PM:
> > 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.
> 
> It is used every time I load a calendar from an unknown source.

Im not sure where you are finding many calendars "from an unknown source" 
but doing a "full property and subcomponent mush" extraction of all 
properties and subcomponents is NOT something you really should be doing 
every time.  It just doesnt scale well, especially if there is lots of 
data in the calendar.   Hmm, perhaps this is why it looks different, the 
wrappers have been stripped away.

Plus, in case you missed it in my reply, you only save 22 octets per 
subcomponent by having the CS remove the top most container wrapper. Thats 
hardly a big justification for this feature give the hassles it causes 
with multiple subcomponents (ie: multiple VALARMs or multiple VEVENTs) 
being all mushed together. 

> The feature is documented. And works. And even if you do not want to use 

> the feature
> it appears from this conversation that you did understand from  CAP 
> what that
> feature does when called. 

I fully get the technical aspects of the bits Im questioning.  Im 
questioning their actual pratical use / benefit.  Just because you have 
protoyped up code based on the current text does not mean that its the 
correct thing to have in CAP.

Having the CS strip off the BEGIN/END markers has 2 effects:

1: It saves a mere 22 octets of data per subcomponent being returned and
2: Causes the data belonging to all subcomponents to bleed together into a 
mush that makes separate subcomponent identification and use impossible

Please show me how this is useful.

> And I thought that feature changes were off topic and we were into get 
> CAP done mode.

This thread has evolved into a questioning of the CAP design from my 
original question.  Asking questions of the design is still allowed in the 
WG last I checked.  By now it should be simple enough to give a good 
justification for everying in CAP; otherwise it has not been properly 
thought out and clearly described. 

Given the 2 points above I find it hard to say that this was fully thought 
out and this part may need some reworking (or simplification).  Perhaps 
this is an artifact of our backtracking from using SQL as the query lingua 
(as evident by the column / table phrasing in Section 6.1.1 still). 
Perhaps its an artifact of having so many editors over time that some 
things just did not make it into the current text like they should have.

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

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