Subject: Re: CAP: Badly formed SQL

From: "John Stracke" <[email-masked]>
Date: Fri, 11 Jan 2002 12:35:57 -0500

>Does this make any sense,

It could work...but it's starting to get pretty baroque, especially when 
you start thinking about parameters on properties in subcomponents (for 
example, a VALARM with a RELATED parameter on its TRIGGER).

>and would there be a clean way
>of coping with multivalues like this?

I think the answer is still no.  Multivalues just don't fit into SQL's 
relational model; you have make them explicit.

I think we might want to do a simple constraint-based model.  I'll see if 
I can write something up over the weekend.

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|Illiterate? Write today for free help!                 |
\=======================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 11 Jan 2002 12:10:43 -0600

An issue that I discovered in my own attempts to use a SQL backend for
iCalendar was that there is a complexity to handling elements that have
MULTIPLE possible data types (i.e. anything that could be a DATE or a
DATETIME) - this requires multiple tables and a series of joins/queries to
extract just one object.

i.e. you can not easily have a single VEVENT table with a column for DSTART
which holds the actual VALUE for that particular event - rather it must
reference at least one (and probably more than one) additional tables to
compose for that particular instance the data of the correct type for what
you are doing - and this makes it more complex to then use the underlying
SQL database as an engine for common calendaring actions (such as getting
all the events occurring on a given day...)

In many ways the iCalendar data model argues for an Object Oriented database
model - this raises the ongoing issue however of how to then query and/or
store those objects.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Friday, January 11, 2002 11:36 AM
To: [email-masked]
Subject: Re: CAP: Badly formed SQL

---

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

> DATETIME) - this requires multiple tables and a series of joins/queries to

Yes. But that is in the CS implementation. I am hoping that
we can define that the CUA side just thinks that there is
a predefined schema and a CS that supports NO joins.
Then the CS using the spec, knows how to do these hidden joins.

> all the events occurring on a given day...)

Yes.