Subject: Re: RELATED-TO vs CHILD/PARENT

From: Alan Davies <[email-masked]>
Date: Wed, 09 Jan 2002 13:54:54 -0500

At 01:17 PM 09/01/2002 -0500, John Stracke wrote:
>The only problem I see with "." is that, in a SQL statement, it looks like
>the "table.column" syntax for use in a join.  It might become ambiguous if
>somebody defines a property for VALARM named, say, VEVENT, which has a
>parameter named UID (a backpointer from VALARM to the event that contains
>it):
>
>SELECT * FROM VEVENT, VALARM WHERE VEVENT.UID=VEVENT.UID;

Your example could have looked a little less ambiguous like this:

SELECT * FROM VEVENT, VALARM WHERE VEVENT.UID=VALARM.VEVENT.UID;

This still doesn't make much sense in SQL; as you said in a different
mail there's no way of specifying a 'subcolumn' in SQL, so anything
(even the period) that is chosen to delimit the parameter would be
non-standard SQL:

VEVENT.ATTENDEE.PARTSTAT
VEVENT.ATTENDEE->PARTSTAT
VEVENT.ATTENDEE;PARTSTAT
VEVENT.ATTENDEE[PARTSTAT]
PARAM(VEVENT.ATTENDEE,'PARTSTAT')

--Alan

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jan 2002 14:16:21 -0700

Alan Davies wrote:

> mail there's no way of specifying a 'subcolumn' in SQL, ...

But if we define that we ~MAP~ in our 'virtual database', 
properties as tables and parameters as columns, does it
then work for CAP?

> ... so anything

As in?
 It would be valid syntax, but perhaps not a valid Schema
 and the CS would have to do work to map it into a valid schema?

If you think that it is valid syntax and map-able into a
valid schema, then we achieved our goal?

We did agree that we would not specify a specific schema, just
how to map iCalendar records into and out of our VQUERY. Does
specifying that properties as virtual tables, and parameters
as their virtual columns solve the issue? I think it does.

> VEVENT.ATTENDEE[PARTSTAT]

This also looks valid, are you proposing this next one?

---

From: Patrice Lapierre <[email-masked]>
Date: Wed, 09 Jan 2002 17:08:43 -0500

If we use following mapping for the 'virtual dabase':
	table == component
	column == property

then from my understanding of SQL-92 ATTENDEE.PARSTAT is not 
valid syntax.

  It might be in SQL-99 or SQL3, I believe that they added 
structural types (similar to struct in C) that uses the
dot notation.

  If SQL-92 compliance is a must, then the simplest approach might 
be to simply use a function:

	PARAM(ATTENDEE,'PARTSTAT')

  It not pretty, but the syntax is valid and functions are 
frequently used in SQL (e.g. COUNT()).

---

From: Alan Davies <[email-masked]>
Date: Wed, 09 Jan 2002 17:27:17 -0500

>properties as tables and parameters as columns, does it

I don't think so, as the 'table' is specified in the
'from' clause, and we want our 'table's to be components.

>valid schema, then we achieved our goal?

It's not valid SQL92, as you could write things such
as this:

     select ATTENDEE.PARTSTAT from VEVENT where [...];

which just doesn't make sense, as ATTENDEE is not a
named table in the 'from' clause, which the 'select'
is implying.

Without parameters, it's easy to specify valid SQL92:

     select VEVENT.UID from VEVENT where [...];
     select UID from VEVENT where [...];

--Alan

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jan 2002 15:53:48 -0700

> then from my understanding of SQL-92 ATTENDEE.PARSTAT is not

I'll bring in my $$$ copy of 'the spec' for SQL-92 tomorrow
and look it up. I had thought I got it out of that spec, but
I could have just thought it was there from my knowladge
of SQL.

> frequently used in SQL (e.g. COUNT()).

I could live with that if '.' is in fact not SQL-92.
We agreed on SQL-92 because the experts at the time said
that was a good mix of functional and not too envolved.
I would rather we no re-open that debate. If at all possible
lets get it to work with correct SQL-92 'syntax' - what ever
that happens to be.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jan 2002 16:03:07 -0700

> 'from' clause, and we want our 'table's to be components.

We want them to be what it takes to make it work :-)

Would you be happy with what Patricel suggested?

---

From: Alan Davies <[email-masked]>
Date: Wed, 09 Jan 2002 18:13:53 -0500

>         PARAM(ATTENDEE,'PARTSTAT')

It's the only suggestion so far that doesn't violate
SQL92's syntax, so it looks good to me.

--Alan

---

From: Alan Davies <[email-masked]>
Date: Wed, 09 Jan 2002 18:11:58 -0500

>I could live with that if '.' is in fact not SQL-92.

'.' is SQL-92, but it qualifies the table (component)
for a column (property).

--Alan

---

From: Patrice Lapierre <[email-masked]>
Date: Wed, 9 Jan 2002 21:00:26 -0500

> I could live with that if '.' is in fact not SQL-92.

 So could I. The important thing is to add the ability to 
search on parameters.

> lets get it to work with correct SQL-92 'syntax' - what ever
  
  There is one thing that I would like to add to the discussion.
Currently SQL-MIN is probably not SQL-92 compliant. 

  One example that comes to mind is the type of properties.
Unfortunately, I don't have the specs, but I think that SQL-92
only includes a predefined set of types. And I doubt that the 
types of all iCalendar properties are supported in SQL-92.

  As mentioned in Doug message, yes we should try to follow 
SQL-92. But the domains of CAP and SQL are not identical.
Therefore I don't think that it is in the best interest of CAP to 
force the query language to conform exactly to SQL-92.

  Of course all differences should be documented, otherwise 
the capability query-level SQL-92 is meaningless.

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 13:25:42 -0700

> types of all iCalendar properties are supported in SQL-92.

"Type of properties"? There is no type of property that
can not be stored into SQL that we have defined.
I do not know what you mean.

> force the query language to conform exactly to SQL-92.

Domains? Correct, but what does that have to do with
a query language? 

> the capability query-level SQL-92 is meaningless.

You did not mention any differences, you only mentioned
that you think that there might be differences.