Subject: Re: CAP: Badly formed SQL

From: Alan Davies <[email-masked]>
Date: Thu, 10 Jan 2002 14:12:23 -0500

At 11:27 AM 10/01/2002 -0500, [email-masked] wrote:
>Having forgotten most of the SQL I knew from my dB days I dont see that 
>any joins, etc are really going to happen (or should happen).  Just 
>because we use SQL-MIN does not mean we are mandating that the CS actually 
>use SQL as its engine, right??

We don't mandate the engine used by the CS, but even
query-min as defined in the ABNF of Section 4.1.1
allows for joins:

     select VTODO.UID
         from VEVENT,VTODO
         where VEVENT.UID = 'ABCD'
         and VTODO.ORGANIZER = VEVENT.ORGANIZER

     (i.e. give me the UIDs of all VTODOs which
      with the same organiser as a given event).

Maybe query-min should be made more restrictive?

I missed the reasoning behind the original decision
to use a subset of SQL; it seems that SQL is not
powerful enough to allow us to express the
(current) iCalendar model effectively but allows
for complex queries to be built, which would be
a real headache for non-SQL engines to interpret.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 15:40:28 -0700

> Maybe query-min should be made more restrictive?

I am open to suggestions.

> a real headache for non-SQL engines to interpret.

The reason for the subset is some people did not want to use an
SQL engine and without defining a subset they would have to
implement full SQL-92 parser. And yet no other query language
proposal was made. So it was a compromise to get 
things out the door.

I for one would not care (please don't take this as consensus) if
SQL-MIN went away and it was SQL-92. Others do not agree. It
looks to me as if less desirable, but functional 'function'
call might work - I am still thinking about that. John has some
objections and I am still thinking about them. But we need to
nail this down so we can get CAP out.

Remember - SQL-MIN is the the exact set of minimum commands
that a CUA needs in order to to all of the METHODs. It is NOT,
it is most definatly NOT - a replacement for SQL-92.

IT IS TRUE that you can not do some things with SQL-MIN, that's
the point of having the option for SQL-92. There was a list
if MINIMUM requirement NEEDED for a CUA to work with respect
to CAP and querying. It was a short list. Does anyone know
if there is anything in SQL-MIN that does not meet those
requirements?

As I reacall we did NOT want SQL-MIN to do complex operations.
We wanted it to be what it took to allow the CUA to get 'stuff',
so that it could do minimum calendaring and schedulting.

For CS's AND CUA's that implement SQL-92 and are talking to
each other -  THEY and THEY ALONE when using SQL-92 can
do much more creative and wonderfull things.

I am trying to find the cap-requirements document.
It spelled out what a CS must do at a minimum.

---

From: Alan Davies <[email-masked]>
Date: Thu, 10 Jan 2002 18:40:48 -0500

>nail this down so we can get CAP out.

I'm not knocking SQL-MIN; the problems pointed out by John, Patrice,
and myself such as parameters, sub-components, multiple properties
etc. are just as present in SQL-92.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 17:55:22 -0700

> etc. are just as present in SQL-92.

Would PARAM(prop-name, param-name) solve the problem if we
specify no joins?

Given that we need a query language. And we have to have a query
language. What minimum tweaks would we need? And what restrictions
could we live with?

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 10 Jan 2002 21:36:38 -0500

On Thursday 10 January 2002 07:55 pm, you wrote:
> language. What minimum tweaks would we need? 

  I think that the minimum should address at least the limitations recently 
posted on the list:

  1 - Query on parameters (we already have some propositions).

  2 - Non-ambiguous conditions on multiple attendee values and parameters.

  3 - Query on multivalues (e.g. CATEGORIES).

The following features already part of SQL-92, but not SQL-MIN:

  4 - Parenthesis are used in some examples of the draft,
       but not part of SQL-MIN ABNF.

  5 - The LIKE operator for strings, seems essential if a CUA want to 
       provide a search panel.

  The second option is probably the one that requires more work.

**NOTE TO EDITORS**  the definition of "colvalue" is missing from the 
ABNF of section 4.1.1

Something that would be nice, but not a must is the IN operator:

Example:

   QUERY:SELECT * FROM VEVENT,VTODO
     WHERE METHOD = 'REQUEST' OR METHOD = 'ADD' OR
            METHOD = 'PUBLISH' OR METHOD = 'CANCEL' OR
            METHOD = 'REPLY'  OR METHOD = 'COUNTER' OR
            METHOD = 'REFRESH' OR METHOD = 'DECLINECOUNTER'

  Could be rewritten as:

  QUERY:SELECT * FROM VEVENT,VTODO
     WHERE METHOD IN 'REQUEST', 'ADD', 'PUBLISH', 'CANCEL',
            	            'REPLY',  'COUNTER', 'REFRESH',
			'DECLINECOUNTER'

--
Patrice.