Subject: Re: SQL virtual schema psudo proposal

From: "John Stracke" <[email-masked]>
Date: Fri, 11 Jan 2002 14:53:36 -0500

>There is no PROPERTY or PARAMATER caled 'VALUE'.

You proposed that the value and parameters of a property would be columns. 
 A column must be referred to by name.  So, for example, you couldn't 
refer to DURATION on its own (it's a table name, not a column name); you'd 
have to refer to DURATION.VALUE.  We could pick something other than 
VALUE, of course, but we'd have to pick something.

>I am proposing that we force the CUA to do more work by
>not allowing those cross-virtual-table joins.

Er...then it will be impossible to make the query "get all events on this 
day", because the DTSTART and DTEND properties are in separate virtual 
tables.  No?

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|Belief is not relevant to truth.                       |
\=======================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Fri, 11 Jan 2002 14:39:05 -0600

And to follow up further - the concept of "all events on this day" requires
the following additional steps be handled:

1. "this day" be defined (with respect to TIMEZONE etc)

2. DATE and DATETIME values on both DSTART and DTEND are evaluated for
"being in the range" - this may include multiple evaluations of referenced
VTIMEZONES

3. Reoccurrence rules are evaluated in some manner (including checking
exceptions which may be yet another table) to return the full set of events
"in range"

There may be further complications if "this day" is defined in a non-fixed
manner (for example - the 4th day of the week - which is then dependant on
the setting for "week start")

Shannon

- this is a major complicating factor in the creation of a CS - clearly
these are implementation issues - but they also point to significent
complicating factors in our underlying data formats and data assumptions (as
encoded in both 2445 and CAP) - all of which I suspect are delaying the
creation of compliant servers, and the adoption of these standards.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Friday, January 11, 2002 1:54 PM
To: [email-masked]
Subject: Re: SQL virtual schema psudo proposal

---

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

> day", because the DTSTART and DTEND properties are in separate virtual

As in 'they can be viewed' in separate virtual tables.

So,

	SELECT * FROM VEVENT WHERE VEVENT.DTSTART ...
			     AND VEVENT.DTEND ...
			     ...

Would work, because to the VEVENT table, DTSTART and DTEND are
columns in the virtual VEVENT table (with their values).

---

From: Alan Davies <[email-masked]>
Date: Fri, 11 Jan 2002 16:14:23 -0500

>columns in the virtual VEVENT table (with their values).

That's a simple case: How would the parameters on the
properties of a VEVENT's VALARM appear in the virtual
VEVENT table?

--Alan

---

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

> properties of a VEVENT's VALARM appear in the virtual

As if the property was a simple virtual table. Again SQL-MIN
is NOT a full blown query language. It is the minimum set
of what it would take to get a CUA to work based on
the cap-requirements.

Trigger time only properties.

	SELECT TRIGGER FROM VALARM WHERE VALARM.TRIGGER ...

Then parse any paramaters in the CUA.

---

From: Alan Davies <[email-masked]>
Date: Fri, 11 Jan 2002 17:05:44 -0500

>Then parse any paramaters in the CUA.

So if VALARM is a virtual table as well, how is it's
relationship to the VEVENT virtual table expressed?
surely these VALARMs will be returned to the CUA
within a VEVENT component, as they're fairly meaningless
on their own?

Also this would only allow the value of a property
to be queried, not the property parameters; is this
acceptable?

--Alan

---

From: Doug Royer <[email-masked]>
Date: Fri, 11 Jan 2002 16:08:06 -0700

> within a VEVENT component, as they're fairly meaningless

Not when is all you want is the VALARMS that will TRIGGER
in some time range. If the VALARMS have an ID (and I think
we have consensus that point), then the CUA can map them to
the VEVENTs (or whatever) they came from.

> to be queried, not the property parameters; is this

I would accept this for SQL-MIN.
We could use functions for SQL-92 0R an add-on draft.