Subject: Re: Updated CAL-QUERY

From: [email-masked]
Date: Wed, 23 Oct 2002 16:12:17 -0400

Doug wrote:
> I added cap-val and included the 'PARAM()' call, so we can
> select ATTACH types and help with the ATTACH problems.

Did you also add text to define how property parameters were to be treated 
as well??  Since there is text in 6.1.1 that says:

   1.  For the purpose of a query, all components should be handled as
       tables, and the properties of those components, should be handled
       as columns.

   2.  All VAGENDAs and CS's look like tables for the purpose of a
       QUERY.  And all of their properties look like columns in those
       tables.

but there is no mention of how property parameters are to be handled. 
Otherwise its unclear just how property parameters should be handled (ie: 
searching for any ATTENDEE property that contains a CN property parameter 
that contains, say, "Contractor" in it or that has an PARTSTAT=ACCEPTED 
and I only want some property parametes of it...).

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Oct 2002 14:43:51 -0600

In -09-2:

6.1.1.3 PARAM()

    Used in a CAL-QUERY.  Returns the value of the named parameter from
    the named property.  If there are multiple properties in the object,
    then PARAM() returns a comma separated list of parameter values.  If
    needed each value can be quoted or contain backslash escaped
    contents.

    When used in a "SELECT" clause, it returns the entire property and
    all of that properties parameters (the result is not limited to the
    supplied parameter).  If the property does not contain the named
    parameter, then the property is not returned (It could however be
    returned as a result of another "SELECT" clause value.) If multiple
    properties of the supplied name have the named parameter, all
    properties with that named parameter are returned.

    When used in the "WHERE" clause, a match is true when the parameter
    value is "IN" or "LIKE" compare clause according to the supplied
    WHERE values.  If multiple named properties contain the named
    parameter, then each parameter value is compared to the condition and
    if any match, then the results would be true for that condition the
    same as if only one had existed.

I *think* that covers it - or did I miss your point?

[email-masked] wrote:
> Did you also add text to define how property parameters were to be 
> treated as well??  Since there is text in 6.1.1 that says:
> 
>  Otherwise its unclear just how property parameters should be handled 
> (ie: searching for any ATTENDEE property that contains a CN property 
> parameter that contains, say, "Contractor" in it or that has an 
> PARTSTAT=ACCEPTED and I only want some property parametes of it...).
>
-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: [email-masked]
Date: Mon, 28 Oct 2002 15:09:08 -0500

> 6.1.1.3 PARAM()
[Snip]
> I *think* that covers it - or did I miss your point?

Missed it.  Let me try to be clearer (kinda hard to get really focused 
after a big product end push followed by vacation, sorry.)

In -09b (ftp://royer.com/pub/CALSCH/cap.txt), at the top of Section 6.1.1 
is:

so there is explicit text on how components and properties are to be 
viewed/treated.  There is no explciit text _here_ on how to deal with 
propery parameters, the next "step down" in scale.  I think there should 
be so that its consistant and unified.  Having text in 6.1.1.3 where 
PARAM() is defined is not consistant and I would not have thought to look 
there since 6.1.1 already lays out the guidelines for how some entities 
are to be handled. 

Put into semi-graphical form, by the text above I would create a table for 
a single VEVENT that was layed out like:

SUMMARY
DESCRIPTION
ATTENDEE
ATTENDEE
ATTENDEE
...
A quick CAP issue discussion
Try to iron out a solution to the...
mailto:[email-masked]
mailto:[email-masked]
mailto:[email-masked]
...

(by "Rule" #1)  So just where do property parameters get stored in this 
model of the data?   I cannot see how I can search for the CN="John Doe, 
Contractor" property parameter on any ATTENDEE since its not clear how its 
handled in the model as described.

Hmm, the more I look @ it in this format the more I wonder why #1 and #2 
do not say "should be handled as rows where the 1st column of the table is 
the property name and the 2nd column is the property value(s)."..

Also, the text in 6.1.1.3 does not describe how property parameters are to 
be handled like in 6.1.1, it describes the actual value restrictions, etc.

Is that clearer?

Bruce