Subject: Re: CAP draft 07 issues - sections 3 and 4

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Mar 2002 17:30:01 -0500

>>     SELECT * FROM VEVENT WHERE
>>         ATTENDEE = "[email-masked]"
>>         AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED
>> 
>> You see the VEVENT contains an ATTENDEE whose value matches
>> "[email-masked]", and an ATTENDEE whose PARTSTAT matches
>> "ACCEPTED", so it would be considered a match if each time
>> the ATTENDEE property was used, it was taken to mean
>> "any ATTENDEE of the VEVENT".
>
>   BEGIN:VEVENT
>     [...]
>     ATTENDEE;PARTSTAT=NEEDS-ACTION:[email-masked]
>     ATTENDEE;PARTSTAT=ACCEPTED:[email-masked]
>     END:VEVENT
>
>When would you ever want it to match a value of one property, and 
parameter
>of another property for the same property name?

Well, for example, the query above could usefully mean, "give me all 
events where Fred is invited and at least one person has accepted".  Also, 
consider this:

     SELECT * FROM VEVENT WHERE
         ATTENDEE = [email-masked]'
         AND PARAM(ATTENDEE, PARTSTAT) = 'ACCEPTED'
        AND ATTENDEE=[email-masked]'

Which ATTENDEE does the PARAM go with now?

/================================================================\
|John Stracke                    |Principal Engineer             |
[email-masked]   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|I'm on a Mission From God to Save The World from megalomania!   |
|(Question: which God? Answer: Milhouse, God of Humility. You    |
|probably haven't heard of him; he doesn't put himself forward.) |
\================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 16:12:53 -0700

> events where Fred is invited and at least one person has accepted".  Also, 

We decided on no cross-table joins, and that is what it looks like
to me. We stated that all parameters look like columns in a
conceptional property table. So you are asking to join from
the value of one component table (table=vevent col=attendee, value=fred)
to the value in another table (table = attendee, col = partstat,
value = accepted).

That is a cross table join - no you can not do that in CAP-QL.

---

From: Robert Lusardi <[email-masked]>
Date: Mon, 25 Mar 2002 19:07:32 -0500

>>Which ATTENDEE does the PARAM go with now?
Well, I can certainly tell you how SQL would do it, but I don't want to 
drag the conversation down to that (did I just hear someone say "Too 
Late!" :-).

My point was that I keep hearing in the emails how the query language is 
"based" on SQL, so the question becomes how much is it based on SQL, and 
at what point does it deviate?  Is (are) the point(s) of deviation the 
place(s) that make(s) the most sense? And do the resolutions make the 
most sense?

My homework is to read up, and then shut up if I don't have an alternative.

rob

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 19:09:29 -0500

At 04:12 PM 25/03/2002 -0700, Doug Royer wrote:

>to me.

We decided against cross-component joins; and it's self-evident
that the effect of giving a name to instances of a multi-property
could be described as a sort cross-property join (within one component).
This was never stated as such on the list though, and so there can
have been no consensus either for or against it.

>We stated that all parameters look like columns in a
>conceptional property table.

That may or may not have been discussed at some point in the discussion,
but that's not the model that we decided upon. PARAM() looks like an SQL
function that takes a column name and a parameter name, and returns
a value, in the same way that SQL-92 built in functions are used.

>So you are asking to join from

I'm afraid that really doesn't make much sense; the issue of joins
between properties is nothing to do with the parameters. The values
of the properties could just as easily have been used in the query,
not the parameters.

--Alan

---

From: Alan Davies <[email-masked]>
Date: Tue, 26 Mar 2002 11:17:13 -0500

>drag the conversation down to that (did I just hear someone say "Too 

It's never too late to correct something if it really is broken.

>place(s) that make(s) the most sense? And do the resolutions make the most 
>sense?

CAP-QL really just "uses an SQL-like syntax".

In the CAP draft, some analogies are drawn between the way
components/properties and SQL tables/columns are queried to aid in
the reader's understanding, but it's misleading to take that
analogy too far - it's _not_ SQL.

The reason it deviates, is due to the extra complexity of the iCalendar
data model, as has been stated before. Perhaps this difference makes
SQL a bad choice- a decision was made by someone to make it look like
SQL a long time in the past, perhaps before these issues were fully
understood.

Perhaps we really do need to accept that an SQL-like syntax isn't really
viable without introducing some extra relational-db style 'columns', to
work around the child-component/multi-property/parameter complexities.

>My homework is to read up, and then shut up if I don't have an alternative.

Please don't shut up, as what you say is making sense.

--Alan