Subject: Re: CAP: Badly formed SQL

From: [email-masked]
Date: Fri, 11 Jan 2002 14:13:43 -0500

Doug wrote on 01/10/2002 03:32:23 PM:

> If you did that in SQL you would get data. It might not
> be the data as sited in the text.

Whoa!  I thought we agreed a long time ago (DC IETF) that we were NOT 
using SQL as the lingua.  We were going to be SQL like.  As such, we dont 
need to make the queries "valid SQL" as long as our format can be mapped 
to any desired engine (including SQL).

Did this change and I not see it?!?!  Given all the discussion of late 
about our examples bieng valid or invalid I suspect some think that we are 
using SQL as the query langage and are not SQL like any more.  This was 
never discussed or agreed on!

> Correct - but we did agree that a person that knew SQL would
> be able for form a query given our 'virtual database' mapping.

So then all the other threads under assorted topics about our queries 
being valid or invalid SQL are moot, no??  We just need to be clear what 
we mean by and so someone can map it to valid SQL (or some other engine).

> We also agreed and it is (or used to be) in cap were it said
> that each data set that was returned would be encapsulated
> in a BEGIN/END VCALENDAR. So if you got the data from
> 10 components, you would get 10 BEGIN/END VCALENDAR objects

Huh!?  When did this happen?  There is no reason I can think of now to 
justify this.  After all the ABNF for iCalendar allows multiple VEVENTS, 
VTODOS, etc to be inside 1 single VCALENDAR.  So why do we have to return 
10 VEVENTS inside separate VCALENDARS???!!!

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]

---

From: Doug Royer <[email-masked]>
Date: Fri, 11 Jan 2002 13:52:53 -0700

> > be the data as sited in the text.

(my point above was that the example was bad)

> using SQL as the lingua.  We were going to be SQL like. 

No - we agreed we would NOT require an SQL engine in the CS. 
And we agreed the syntax would be SQL. And in DC we reviewed the
proposal made in Orlando and decided that it would be SQL syntax
if at all possible.

We also agreed that we would *not* have an SQL-like syntax
because that meant that we would have to have a year long
debate like the WebDav people did. They later said they wished
they would have chosen SQL syntax and just concentrated on
their virtual database (they made this statement in Orlando).
By not going with SQL syntax, they had to invent a query language,
invent a virtual database, then spend a year trying to get everyone
to agree if their version of SELECT, FROM, and WHERE statements
we a little like SQL, exactly like SQL, or just happened to be
spelled the same.

> As such, we
> dont need to make the queries "valid SQL" as long as our format can be
> mapped to any desired engine (including SQL).

Yes and no.

If at all possible they should be valid SQL so everyone knows
what a SELECT, FROM, and WHERE means. However we may (and now it
looks as if we do) have to specify the virtual schema.

> about our examples bieng valid or invalid I suspect some think that we
> are using SQL as the query langage and are not SQL like any more.
>  This was never discussed or agreed on!

Yes we did - Minneapolis time frame.

> being valid or invalid SQL are moot, no??  We just need to be clear
> what we mean by and so someone can map it to valid SQL (or some other
> engine).

Not moot. They are bringing out issues that need to be solved.
And I am hoping that we can continue to use valid SQL. So far
it looks as if it will work.

> justify this.

If you look at the example I also sent, you'll see I did what
I meant to say :-) Please read my mind :-)

>  After all the ABNF for iCalendar allows multiple
> VEVENTS, VTODOS, etc to be inside 1 single VCALENDAR.  So why do we
> have to return 10 VEVENTS inside separate VCALENDARS???!!!

I agree one BEGIN/END VCALENDAR with multiple VEVENTs. I think
that was in the text that I sent.