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

Doug replied on 06/07/2004 11:44:34 AM:
> I did not see any new questions that had not already been answered.

There was 1 question and one non-direct question that have not been 
answered yet.  First the non-direct question:

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

To make it a formal question then; Can anyone please show me how this is 
really useful?

The undiscussed/unanswered question:

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

In the interest of saving time and merging this thread with the other one 
about "*.*" I have a proposal that will:

A: Resolve any ambiguity related to the usefulness of "component.*" vs 
"component" on searches
B: Allow for property discovery without the need for full contained 
component retrieval.
C: Remove the undefined "*.*" special case need for some containers that 
matches the (semi) defintiion of "*" in Section 6.1.1
D: Remove the useless case of returning subcomponent data without the 
BEGIN/END wrappers.

Given:

1: There are times when a CUA wants to perform property _discovery_ 
instead of actual property _processing_ (implicitly described by Doug 
although never actually addressed in CAP text) and
2: The lack of subcomponent BEGIN/END wrappers saves a mere 22 octets BUT 
results in an unprocessable mush of subcomponents and properties and
3: There is at least one ambiguity/conflict between the use of "*" and 
"*.*" in the current text 

I propose we make the following simple changes to CAP that will address 
and resolve all the questions/issues found to date:

        (A) We remove any concept of "component.*" vs "component" in CAP 
(essentially bullet item 7 in Section 6.1.1).  Whenever a subcomponent is 
requested, it will ALWAYS result in that entire subcomponent being 
returned intact (wrappers NOT removed).  In the SELECT clause, there never 
should be a "component.*" or "*.*" usage necessary.

        (B) To simplify things, we define the use of "*" in the SELECT 
clause to only refer to properties or entire containers.  We change bullet 
7 to Section 6.1.1 that says:

        7. When the "SELECT" clause of the query contains an "*" value, 
contained 
           components are not automatically included in the returned 
results.  Only
           those properties found in the component in the FROM clause (or 
the
           implicit container in the case of VCALSTOREs and VAGENDAs) are 
returned.
           If the requestor wants contained components to be included in
           the returned results, they need to expressly request the 
desired
           contained component(s) (or all of them) using the proper 
"INCLUDE"
           clause.  Contained components are always returned with their 
           BEGIN/END markers intact so that component integrity is 
maintained 
           and no mismatching of properties will accidentally occur.  To 
indicate
           all contained components should be included, the value of "*" 
should
           be used in the "INCLUDE" clause of the query.  To indicate all 
properties
           but no contained components should be returned, no "INCLUDE" 
clause would
           be used in the query.
        8. When the "SELECT" clause of the query contains a contained 
component,
           the entire contained component is returned along with its 
BEGIN/END
           markers so that component integrity is maintained and no 
mismatching of
           properties will accidentally occur.

        (C) We slightly change the cal-query ABNF to allow the requestor 
to simply and direclty indicate which subcontainers they want, if any.  We 
also remove the questionable ability to SELECT subcomponet values only. 
        We change the ABNF to:

     cal-query  = "SELECT" SP cap-val SP
               [ "INCLUDE" SP cal-include SP ]  ; ONLY occurs when the 
"SELECT" cap-val contains an "*" value
               "FROM" SP comp-name SP
               "WHERE" SP cap-expr

             / "SELECT" SP cap-cols SP
               [ "INCLUDE" SP cal-include SP ]  ; ONLY occurs when the 
"SELECT" cap-val contains an "*" value
               "FROM"   SP comp-name

     cap-val  = cap-cols
           / param
             / ( cap-val "," cap-val )

     cap-cols = cap-col-select 
           / ( cap-cols "," cap-col-select) 
           / "*"

     cap-col-select    = comp-name
                       / cap-prop

     cal-include  = all   ; This value indicates ALL subcomponents are 
desired
             / comp-name    ; This value indicates a particular desired 
subcomponent
             / ( cal-include "," comp-name) ; This value indicates a list 
of desired subcomponents

        to reflect that the CUA now clearly indicates if they want any 
subcomponents or not and which ones even (so its not an "all or nothing" 
deal). 
        "all" is already defined elsewhere in CAP ABNF. 
        Also, the ability to use subcomponent properties in "WHERE" 
clauses is still intact.  This means that you can still use queries like 
that of (e) in Section 6.1.1 without actually having to retreive the 
VALARM too.

        (D) We remove the text in CAP that special cases "*.*" for 
VCALSTORE and VAGENDA since it is no longer necessary with the above 
changes.

Thoughts / comments / feedback?

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