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

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Mar 2002 15:26:27 -0500

>> whether the two references to ATTENDEE in the first two examples
>> would refer to the same or different properties).
>
>In what case would 'two' ATTENDEEs be from the 'same' property?
>ATTENDEE is a single valued, multiinstance property.

Yes, but the SQL syntax can't know that, since it has to be able to cope 
with properties added in the future.

If we dropped USING_PROPERTY, we'd be left with three choices for how to 
deal with "property relop1 value1 AND property relop2 value2" (where relop 
is a relational operator such as = or <=):

(a) Both references to "property" always refer to the same instance.  In 
this case, "ATTENDEE=[email-masked]' AND ATTENDEE=[email-masked]'" 
will always be false--not very useful.

(b) "property relop value" always means "there exists some instance of 
property such that property relop value".  In this case, 
"VALARM.DTSTART>=20020325T000000Z AND VALARM.DTSTART<=20020325T235959Z" 
means "there exists a VALARM A that starts after 20020325T000000Z and another VALARM B, possibly the same as A, that starts 
before 20020325T235959Z".  Again, not very useful.

(c) Define, on a property-by-property basis, which of (a) or (b) applies 
for each property in 2445.  Lots of work, lots of potential for error, 
difficult to maintain as 2445 evolves.

I don't think any of these is viable; I think we need to keep 
USING_PROPERTY (and USING_PARAMETER, too, by the same reasoning).

/==============================================================\
|John Stracke                    |Principal Engineer           |
[email-masked]   |Incentive Systems, Inc.      |
|http://www.incentivesystems.com |My opinions are my own.      |
|==============================================================|
|"I'm sorry, Wizowsky, Randall says I'm not supposed to talk to|
|victims of his evil plots." -- _Monsters, Inc._               |
\==============================================================/

---

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

>As far as I've been following all the threads, CAP's query requests 
>follow SQL.

The problem is that the iCalendar data model contains many multivalued 
properties (etc.), which means that we can't quite use standard SQL to 
query them.  For example:

>The example query with VALARM would *only* return VEVENTS whose alarm 
>values were between those two dates. Again, not ambiguous at all.

There could be more than one VALARM on the same VEVENT, though.

>As someone who is very familiar to SQL 

(BTW, everybody, I can vouch for that; Rob was one of the SQL gurus at 
eCal.)

>the use of USING_PROPERTY and 
>USING PARAMETER are just needlessly confusing.

Unfortunately, they're needfully confusing.

I tried to get the group to drop SQL a couple of months back, and posted a 
proposal that mapped better to the iCalendar data model; but nobody was 
interested (and I didn't have time to push it, because that was the day my 
wife went into labor :-).  The USING stuff was developed as a workaround.

/================================================================\
|John Stracke                    |Principal Engineer             |
[email-masked]   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|"The struggle is always worthwhile, if the end be worthwhile and|
|the means honorable; foreknowledge of defeat is not sufficient  |
|reason to withdraw from the contest." -- Adron e'Kieron, by     |
|Steven Brust                                                    |
\================================================================/

---

From: "John Stracke" <[email-masked]>
Date: Tue, 26 Mar 2002 09:45:35 -0500

>We decided on no cross-table joins,

Actually, I believe we decided against cross-component joins.  If you're 
going to say you can't query on a property and its parameters at the same 
time, queries are going to be pretty limited.

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|If you're going to walk on thin ice, you might as well *dance*!|
\===============================================================/

---

From: "John Stracke" <[email-masked]>
Date: Tue, 26 Mar 2002 09:51:40 -0500

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

These types of questions are what I was talking about back in January, 
when I said 
(<http://www.imc.org/ietf-calendar/mail-archive/msg03009.html>) that being 
SQL-like but not actually SQL would be misleading.  That's why I 
eventually wrote up the non-SQL proposal 
(<http://www.imc.org/ietf-calendar/mail-archive/msg03168.html>).

---

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

To anyone who still hasn't quite grasped the complications that
arise when you assume that SQL can be used to query the
iCalendar data model, please reread John's earlier post that
I quote below, as he explains the issues at hand extremely clearly;
dropping CAP-QL and using the 'simpler' SQL-MIN doesn't begin to
address these issues:

At 03:26 PM 25/03/2002 -0500, John Stracke wrote:
>means "there exists a VALARM A that starts after 20020325T000000Z and 
>another VALARM B, possibly the same as A, that starts