Subject: CAP-13: Another CAL-QUERY / VAGENDA question

From: [email-masked]
Date: Fri, 4 Jun 2004 10:36:21 -0400

In looking at CAP-13 while digesting Dougs recent response to another 
question I ran across an another apparent ambiguity in CAP-13.  In Section 
6.1.1 CAL-QUERY Value Type there is the example:

       (d) SELECT * FROM VEVENT

which is described as:

       (d) Selects every property and every component
        that is in any "VEVENT" component, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

This indicates that the use of "*" in query will return every property and 
component in the FROM component (VEVENT in this case).  However in Section 
9.1 VAGENDA Component I find:

   To fetch all of the properties from the targeted "VAGENDA" component.
   This does not fetch any components:

   SELECT * FROM VAGENDA

   To fetch all of the properties from the targeted VAGENDA and all of
   the contained components, use the special '*.*' value:

   SELECT *.* FROM VAGENDA

which is seemingly contraditory to that of the stuff in Section 6.1.1. Why 
isn't the first example interpreted the same way as (d) was: Every 
property and every component in the VAGENDA? 

The same can be asked of VCALSCALE as well.  There are 2 references to "
the special '*.*' value" but I can find only _those_ actual uses of "*.*" 
in the draft.  There is nothing anywhere in CAP-13 that describes a 
special "*.*" sequence.  No text or any ABNF that I can find. 

Can anyone point me to the parts I missing that describe "*.*"?  I also 
question the need/use of "*.*" for VAGENDA and VCALSCALE.  Why aren't the 
same rules from Section 6.1.1 sufficient for VAGENDA and VCALSCALE but 
they are sufficient for all other components that have the same nesting 
structure?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Fri, 04 Jun 2004 10:05:36 -0600

[email-masked] wrote:

>
> Can anyone point me to the parts I missing that describe "*.*"?  I 
> also question the need/use of "*.*" for VAGENDA and VCALSCALE.  Why 
> aren't the same rules from Section 6.1.1 sufficient for VAGENDA and 
> VCALSCALE but they are sufficient for all other components that have 
> the same nesting structure?

Originally * was designed to NOT get components, later the WG decided
that it was to get components except for VAGENDA and VCALSORE.
Then there was no way to get the properties only for a VAGENDA
and VCALSTORE, so we added '*.*'

We had 1 or 2  interim meeting and phone calls (remember the ones
that you organized?) that kept (among other things) evolving the query 
syntax.
Then there were several edits over time.

We need a way to get top level properties and not contained components.
And we need to way to get everything. '*' vs '*.*' just strings as far
as I am concerned.

-- 

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

              We Do Standards - You Need Standards

---

From: [email-masked]
Date: Fri, 4 Jun 2004 16:05:59 -0400

> > the same nesting structure?
[Snip, snip]
> And we need to way to get everything. '*' vs '*.*' just strings as far

Ahh, now I see.  You dont need it for _retrieving_ top level properties, 
you want it for top level property _discovery_ w/o having to download the 
other subcomponents. 

Thats all fine I think but there is _no_ text in CAP that actually 
_defines_ this explicitly.  There are 2 uses of the phrase "the special 
'*.*' value" but there is no actual CAP text that describes this special 
value or its meaning (and how its different from "*").  Thats my point 
here.

Actually, I think there has been some misunderstanding about "*.*" as 
well.  In CAP-13 I read:

   SELECT *.* FROM VAGENDA

but how is this NOT equivalent to how "*" is used in Section 6.1.1?  That 
is:

   SELECT * FROM VAGENDA

should be the same equivalent as "(d) SELECT * FROM VEVENT" which is 
interpreted as:

       (d) Selects every property and every component
        that is in any "VEVENT" component...

They sure sound the same to me.  Yet I think Doug is saying that the "*" 
case for VAGENDAs and VCALSTOREs is not the same; that "*.*" is the proper 
equivalent.

There is also nothing in Section 6.1.1 that exempts VCALSTOREs and 
VAGENDAs from bullet item 7 that describes the use of "."  nor is there 
any text at all in CAP actually defining what the meaning of "*" is in 
CAP-QL (see other thread).

I can find no text in CAP-13 that says that "*" for VAGENDAs and 
VCALSTOREs is just properties and no subcontainers.  If this had been part 
of the changes we made over time, it got lost from CAP and needs to be put 
back (or in).  In addition, there needs

It is also worth noting that the "*.*" is NOT necessary for property 
retrieval, merely for discovery.  However its not _strinctly_ necessary 
since discovery can be done by using "*", you just have the added mush to 
wade thru.

So, to summarize if I can:

1: There is no text in CAP-13 that actually defines "*."* for VCALSTORE 
and VAGENDA.  There are 2 references to it but no actual defintion of it.
2: The addition of "*.*" for VCALSTORE and VAGENDA are strictly for top 
level property discovery.  It is not necessary for actual top level 
property retrieval.
3: There is text in CAP-13 that makes "*.*" for VAGENDAs / VCALSTOREs 
equivalent to using "*" on all other components (including VAGENDAs / 
VCALSTOREs). 
4: There was intent in the past to redefine "*" for VAGENDA / VCALSTORE to 
mean "no subcontainers, properties only" but we have no actual text to 
this effect.

As previous WG flare ups have shown, we should not leave this kind of 
intent unwritten in the draft for future readers to intuit.   I think we 
need to fill in some of the gaps with actual text expressly codifying our 
intentions.  Anyone averse to clearing this up?

Bruce
Standard disclaimers apply, even where prohibited by law...