Subject: SQL virtual schema psudo proposal

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 19:41:33 -0700

What if we said:

	(1) All components looked like tables including VALARM.
            And their properties looked like columns in those
	    tables. All magicly normalized in CS.

	(2) All VAGENDAs looked like tables.
	    And all of their properties looked like columns
 	    in those tables.
	
	(3) All properties look like tables - somehow auto
            joined to the correct component tables.
	    All of their parameters and value looked like
	    columns in those tables.

	(4) We say that you CAN NOT do cross component-type joins.
	    And that you can ONLY have ONE component, OR ONE property,
	    OR ONE VAGENDA in the the FROM clause.

	(5) Everything in the SELECT and WHERE clause MUST from the
	    table listed in the FROM clause.

	(6) Allow the '.' to mean <table>.<column> when needed for
	    contained components ONLY as long as all were contained
	    (as defined by iCalendar or CAP) in the SINGLE component
	    type named in the FROM clause OR its contained component
	    that MUST BE in the select clause. If you use a contained
	    component in the WHERE clause, you MUST get ALL of
	    that components data - (no '.') in the SELECT clause
            for that contained component type.

	(7) A contained component without a '.' it refers
	    to <compnent>.* with the result being a properly
	    formatted <component>(s) in the data stream, and correctly
	    in the contained component(s).

Then we could say:

	SELECT DTSTART,DTEND,UID FROM VEVENT WHERE <condition>

	which could return MULTIPLE containers:

		BEGIN:VCALENDAR
		BEGIN:VEVENT
		DTSTART:...
		DTEND:...
		UID:...
		END:VEVENT
		BEGIN:VEVENT
		...
		...
		END:VEVENT
		...
		END:VCALENDAR

Then to get a 'component' from within a component we would say
the following and the CUA would have to do more post processing
work than we had thought of before.

	SELECT VALARM,UID FROM VEVENT WHERE VALARM.TRIGGER ...
	
		BEGIN:VCALENDAR

		BEGIN:VEVENT
		UID:xxx-1
		BEGIN:VALARM
		...<entire contents of VALARM>...
		END:VALARM
		END:VEVENT
		
		BEGIN:VEVENT
		UID:xxx-2
		BEGIN:VALARM
		...<entire contents of VALARM>...
		END:VALARM
		END:VEVENT
	
		END:VCALENDAR

I think this falls into making SQL work, we just restrict
what joins, unions, or virtual tables you can specify from the CUA.
As we are not desiging an SQL-UA. Just desigining a way to get
everything out of a CS that a CUA may need.

-Doug

---

From: Alan Davies <[email-masked]>
Date: Fri, 11 Jan 2002 11:25:07 -0500

At 07:41 PM 10/01/2002 -0700, Doug Royer wrote:

>[...]

One thing that strikes me about these extensions to SQL
that we are devising, is that we are moving towards making
SQL-MIN the only realistic query language. Would there be
any practical reason for supporting "SQL-92 with CAP extensions"?
It will be extremely difficult to nail down the impact of our
extensions on every part of the SQL-MIN syntax, let alone
on the complex syntax available in full-blown SQL-92.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Fri, 11 Jan 2002 12:14:59 -0700

> any practical reason for supporting "SQL-92 with CAP extensions"?

I would hope we do not do any extensions.

I hope we could just say the CS can't support *any* kind of joins.

> on the complex syntax available in full-blown SQL-92.

If we could define SQL-MIN to get things done, I would
unhapply agree that we would have to toss SQL-92 - IF NEEDED.