Subject: CAP draft 07 issues - sections 3 and 4

From: [email-masked] (Steve Mansour)
Date: Sun, 24 Mar 2002 16:05:26 -0800

... continued:

Section 3.1

     seems superfluous and covered in BEEP. do we really need this?

Section 3.2

     (already posted to the list because we're trying to resolve
     this now). The XML encoding, while harmless, is superfluous.
     At the meeting in Minneapolis, we were thinking along these
     lines:

          ENCAPSULATION A

          C: MSG 1 2 . 1234 123
          C: Content-type: application/cap+xml
          C:
          C: <cap latency="3" action="ask">
          C: <![CDATA[
          C: Content-Type: text/calendar
          C:
          C: BEGIN:VCALENDAR
          C: METHOD:SEARCH
          ...
          C: END:VCALENDAR
          C: ]]>
          C: </cap>
          C: END

     The XML encapsulation is innocuous, but it adds nothing.
     Further, it tempts us to move things out of the Application
     layer and into the Transport layer (such as the command names,
     and attributes such as "latency" and "action" -- undermining
     the transport/application separation and leading us down
     slippery slopes.  Here is a simpler alternative (and yes, I
     know some of you have been pushing for something like this all
     along :-) :

          ENCAPSULATION B

          C: MSG 1 2 . 1234 123
          C: Content-type: text/calendar
          C:
          C: BEGIN:VCALENDAR
          C: METHOD:SEARCH
          C: LATENCY:3
          C: ACTION:ASK
          ...
          C: END:VCALENDAR
          C: END

     The advantage of encapsulation B is that it represents exactly
     the same content as encapsulation A, but it uses one rather
     than two encapsulations and there are no hints about the
     calendaring commands in the transport. We could substitute
     *any* transport.

Section 3.3

     Second paragraph should end with a sentence describing what
     happens on an aborted command. The easy thing to do is
     something like this:

          Partial results indicating homw much of the command
          completed MAY be returned.

     Or we may want to get more ambitious require a precise reply.

     The third and fourth paragraphs will need to go wherever we
     define Latency and Action.

     The last RPY message on the last example of the section. This
     should probably become an application level error reply rather
     than a transport level reply.

Section 4.1

     bullet (1) -- we should state how to handle Parameters, and
     how to handle components that contain other components.

     bullet (3) -- what is the reasoning behind this limitation?

     bullet (7) -- I'm not sure I understand the problem here. Can
     someone illustrate the point we're trying to make with an
     example?

     bullet (7) -- do we really need USING_PROPERTIES and
     USING_COMPONENTS ?  I don't see the value based on the
     examples.  Is it just a shorthand to save characters?

Section 4.1.1 - FLOATING TIME EVENTS

     We need to clarify how we search for floating time events. If
     we're going to send UTC times in queries, then I don't see how
     we can search for floating time events.  Seems like the only
     way to get the "floaters" is to do a separate query for them
     where we specify the floating time range for the query.

Section 4.1.1

     I'm just confused by reading it. I think it needs to be made
     clearer. The examples are throwing me off.

Section 4.1.1

     bullet (7) -  There's still a reference to CONTAINS().  Also,
     the next to the last paragraph seems like it will be a
     problem. When the schema is updated, servers won't know
     whether a new component / property is multivalued or not.

Section 4.1.1

     bullet (8) - There were some typos fixed, but it seems like
     there are two logic errors.

          '%,%' IN parameter  should match NONE -- currently
          says it matches (d) and (e)
          LIKE(parameter, ',')  should match (e) -- currently
          says it would NOT match any

Section 4.3

     This is really not an issue with section 4.3. It just became
     clear when I read the example. I don't think we've defined
     anywhere that we're moving METHOD into components. We need to
     define this property somewhere. Also, as we're using it in the
     VEVENT, VTODO, and VJOURNAL, it is less an action and more a
     state. It's name should reflect its use.  So, something like
     WORKFLOWSTATE is probably better.

     We need to define when it is set, especially in the iTIP
     workflow. I recommend that the CUA be responsible for
     explicitly setting this

     Another problem associated with this is that when data is
     migrated out of an ITIP wrapper and into a component, it will
     be a lossy transformation as things stand today.  For example,
     consider the following ITIP request:

          BEGIN:VCALENDAR
          PRODID:-//ACME/DesktopCalendar//EN
          METHOD:REQUEST
          VERSION:2.0
          BEGIN:VEVENT
          ...
          END:VEVENT
          END:VCALENDAR

     We are talking about migrating the METHOD:REQUEST value into a
     new component property like WORKFLOWSTATE. But what about
     information like PRODID and VERSION ?  Might those or other
     values contained in the VCALENDAR become significant over
     time?  Do we just toss them?

     One suggestion in Minneapolis was to create a new component
     called VITIP that would contain everything in the ITIP
     request.

     Do we need something like VITIP ?   or is migrating the METHOD
     value into WORKFLOWSTATE good enough?

Section 4.7

     In the example:

          BEGIN:VQUERY
          EXPAND:TRUE
          QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
            USING_COMPONENT VALARM my-alarm
            WHERE my-alarm.TRIGGER >= '20000101T030405Z'
            AND my-alarm.TRIGGER <= '20001231T235959Z'
            AND METHOD = 'CREATE'
          END:VQUERY

     use of "USING_COMPONENT" seems like it's not buying us much.
     Seems like this example could actually be shortened by writing
     it without the USING_COMPONENT line:

          BEGIN:VQUERY
          EXPAND:TRUE
          QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
            WHERE VALARM.TRIGGER >= '20000101T030405Z'
            AND VALARM.TRIGGER <= '20001231T235959Z'
            AND METHOD = 'CREATE'
          END:VQUERY

     The example may simply not constructed to show the real value
     of "USING_COMPONENT".  Can someone describe the real value of
     this?  Or can we drop it?   Same thing for "USING_PROPERTY".

Section 4.7

     The example just reminded me: I propose that we add a UID
     property to VALARM.  We (Netscape) have implemented a calendar
     server where this value is very useful. Our experience has
     been that you have to jump through hoops to figure out which
     of multiple alarms you need to work on if you don't have this
     UID value.

---

From: Gary Frederick <[email-masked]>
Date: Mon, 25 Mar 2002 06:25:34 -0600

Are we to just focusing on the "CAP / BEEP / XML / iCalendar  -  updated 
proposal"?

Would it be useful to take your list of issues and 'schedule' them?

Gary

Steve Mansour wrote:
>     (already posted to the list because we're trying to resolve this
>     now). The XML encoding, while harmless, is superfluous. At the
>     meeting in Minneapolis, we were thinking along these lines:
> 
>         ENCAPSULATION A
> 
>         C: MSG 1 2 . 1234 123
>     The XML encapsulation is innocuous, but it adds nothing. Further, it
>     tempts us to move things out of the Application layer and into the
>     Transport layer (such as the command names, and attributes such as
>     "latency" and "action" -- undermining the transport/application
>     separation and leading us down slippery slopes.  Here is a simpler
>     alternative (and yes, I know some of you have been pushing for
>     something like this all along :-) :
> 
>         ENCAPSULATION B
> 
>         C: MSG 1 2 . 1234 123
>     The advantage of encapsulation B is that it represents exactly the
>     same content as encapsulation A, but it uses one rather than two
>     encapsulations and there are no hints about the calendaring commands
>     in the transport. We could substitute *any* transport.
> 
> Section 3.3
> 
>     Second paragraph should end with a sentence describing what happens
>     on an aborted command. The easy thing to do is something like this:
> 
>         Partial results indicating homw much of the command completed
>         MAY be returned.
> 
>     The third and fourth paragraphs will need to go wherever we define
>     Latency and Action.
> 
>     The last RPY message on the last example of the section. This should
>     probably become an application level error reply rather than a
>     transport level reply.
> 
> Section 4.1
> 
>     bullet (1) -- we should state how to handle Parameters, and how to
>     handle components that contain other components.
> 
>     someone illustrate the point we're trying to make with an example?
> 
>     USING_COMPONENTS ?  I don't see the value based on the examples.  Is
>     it just a shorthand to save characters?
>      
> 
>     We need to clarify how we search for floating time events. If we're
>     going to send UTC times in queries, then I don't see how we can
>     search for floating time events.  Seems like the only way to get the
>     "floaters" is to do a separate query for them where we specify the
>     floating time range for the query.
> 
> Section 4.1.1
> 
>     bullet (7) -  There's still a reference to CONTAINS().  Also, the
>     next to the last paragraph seems like it will be a problem. When the
>     schema is updated, servers won't know whether a new component /
>     property is multivalued or not.
> 
> Section 4.1.1
> 
>     bullet (8) - There were some typos fixed, but it seems like there
>     are two logic errors.
> 
>         '%,%' IN parameter  should match NONE -- currently says it
>         matches (d) and (e)
>         LIKE(parameter, ',')  should match (e) -- currently says it
>         would NOT match any
> 
> Section 4.3
> 
>     This is really not an issue with section 4.3. It just became clear
>     when I read the example. I don't think we've defined anywhere that
>     we're moving METHOD into components. We need to define this property
>     somewhere. Also, as we're using it in the VEVENT, VTODO, and
>     VJOURNAL, it is less an action and more a state. It's name should
>     reflect its use.  So, something like WORKFLOWSTATE is probably better.
> 
>     We need to define when it is set, especially in the iTIP workflow. I
>     recommend that the CUA be responsible for explicitly setting this
> 
>     Another problem associated with this is that when data is migrated
>     out of an ITIP wrapper and into a component, it will be a lossy
>     transformation as things stand today.  For example, consider the
>     following ITIP request:
> 
>         BEGIN:VCALENDAR
>     We are talking about migrating the METHOD:REQUEST value into a new
>     component property like WORKFLOWSTATE. But what about information
>     like PRODID and VERSION ?  Might those or other values contained in
>     the VCALENDAR become significant over time?  Do we just toss them?
> 
>     One suggestion in Minneapolis was to create a new component called
>     VITIP that would contain everything in the ITIP request.
> 
>     Do we need something like VITIP ?   or is migrating the METHOD value
>     into WORKFLOWSTATE good enough?
> 
> Section 4.7
> 
>     In the example:
> 
>         BEGIN:VQUERY
>         EXPAND:TRUE
>     use of "USING_COMPONENT" seems like it's not buying us much. Seems
>     like this example could actually be shortened by writing it without
>     the USING_COMPONENT line:
> 
>         BEGIN:VQUERY
>         EXPAND:TRUE
>     The example may simply not constructed to show the real value of
>     "USING_COMPONENT".  Can someone describe the real value of this?  Or
>     can we drop it?   Same thing for "USING_PROPERTY".
> 
> Section 4.7
> 
>     The example just reminded me: I propose that we add a UID property
>     to VALARM.  We (Netscape) have implemented a calendar server where
>     this value is very useful. Our experience has been that you have to
>     jump through hoops to figure out which of multiple alarms you need
>     to work on if you don't have this UID value.
>

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 09:53:18 -0700

>     seems superfluous and covered in BEEP. do we really need this?

I agree.

>         Partial results indicating how much of the command completed
>         MAY be returned.

I don't follow. What do you mean by partial result? I think that
BEEP covers that. We may need some text to say that the CS
MUST send a final '.' RPY (ANS, NUL, or whatever).

>     handle components that contain other components.

Bullet (1) does not describe how anything is handled. It describes
a virtual view of a virtual schema. In one of the edit versions,
it also said the same thing about properties (tables) vs parameters (columns).

Someone suggested that it be split into two paragraphs. Perhaps
the second part was just accidentally dropped.

>     bullet (3) -- what is the reasoning behind this limitation?

If you had followed the list, several people seem to be terrified that
this might actually be SQL. This limit was placed when there was
pressure to eliminate SQL-MIN vs SQL-FULL. Small devices are
not going to implement a full SQL server just to say they are
a CS. So the easiest thing to compromise on was joins.

If you recall SQL-MIN used to be an exact syntax for a minimum
query. And SQL-FULL was SQL-92 that allowed joins. If we
are going to allow joins, I think we must recall SQL-MIN for
small devices.

>     someone illustrate the point we're trying to make with an example?

It allows:

	BEGIN:VQUERY
	QUERY: ...1....
	QUERY: ....2....
	QUERY:...N...
	END:VQUERY

Rather than having to have N separate BEGIN/END VCALENDAR, each
with its own BEGIN/END VQUERY. (7) just says that the results
are returned the same as if you had done N different SEARCHs.

>     it just a shorthand to save characters?

Your mean (4)?

I agree that they need to be tossed. I really wish you had been
active on the list a few months ago.

>     floating time range for the query.

If the CUA wishes to search for 'today', the CUA knows the
begin and end UTC times for its 'today' and that will be shown
in its QUERY (from UTC-7 to UTC-7 + 24 for 'today'). That will return
all components including floating time components for the CUAs view
of 'today' in UTC. Why would floating time components be any different?

>     bullet (7) -  There's still a reference to CONTAINS().

Yep - missed.

>  Also, the

True, but because 2445 did not stick to one method, or mandate
some rule. There is no way other than to guess for something new.

I hope we stick to the requirement in 2445 that they are multivalued
and any value that contains a comma, MUST BE enclosed in quotes.
The problem is that some may be both multi instances and multi valued.

A bug in 2445 that needs to be fixed, not a bug in CAP. I think
that we need the 'method reviewer' and this WG to force newly
registered values to be multi valued, use quotes, and allow
multi instances. At one point we had said (and in is not in 2445):

		X-FOO:1,2

	is the same as:

		X-FOO:1
		X-FOO:2

I think the only compatible way to fix this is to make that true
and just have to live with the 2445 exceptions (like RRULE).

>         '%,%' IN parameter  should match NONE -- currently says it

NO - (d) and (e) are parameters, it says 'IN property'.
It does not say 'IN parameter'.

And (e) needs a ':value'.

>         LIKE(parameter, ',')  should match (e) -- currently says it

Yes.

>     we're moving METHOD into components.

We are not moving METHOD in component. We are just saying
that a components current state is whatever the METHOD was
that last deposited or tweaked its values.

>     We need to define this property

I can't find it in ANY VEVENT, VTODO, or VJOURNAL in the spec.
I do see it in the VCALENDAR just like in iTIP.

>     recommend that the CUA be responsible for explicitly setting this.

So I can't just send down iTIP objects? No. I would not like that.

>     the VCALENDAR become significant over time?  Do we just toss them?

Not migrating them, just tagging them with their workflow state.
I for one will not be storing the entire iTIP object intact.

>     VITIP that would contain everything in the ITIP request.

Why? It already contains everything it needs.

>     into WORKFLOWSTATE good enough?

I say NO to VITIP, iTIP objects are already self contained objects.

I also say NO to specifically adding any new property to the component
over the wire. Moving METHOD into the component is just a conceptual
thing used for finding things that were deposited into the CS.

>     can we drop it?   Same thing for "USING_PROPERTY".

This was added when some were confused as to how the CS would know
when the VEVENT contained multiple VALARMS that each of the
logical comparisons were from the same VALARM. I gave up the
argument - wish you had read the WG list at that time.

>     to work on if you don't have this UID value.

Steve - you really need to follow the list :-)

There was (and i ~think~ generally accepted) debate about how to
tag VALARMs as LOCAL and non-LOCAL, which included adding SEQUENCE
to VALARMS in order to make them unique. I'll look for the post and
forward it to you.  The problem (in addition to your point) was that
if the ORGANIZER includes VALARMs in a VEVENT (or any component), and
the CU does NOT wish to use those VALARMS (I have to drive 1 hour
and you sent the alarm to 15 minute notice). The proposal allowed
for the CUA to tag VALARMs and enabled or disabled. And how to
tag VALARMs so that the CUA knows they are local and are NOT to
be forwarded to any non-owner.

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 13:41:39 -0500

>are going to allow joins, I think we must recall SQL-MIN for

Do you mean recall in name only, or recall the specification
that existed previously as SQL-MIN?

>active on the list a few months ago.

The examples referred to were simple, and did not demonstrate
the value of these clauses.

USING_PROPERTIES and USING_COMPONENTS allow instances of multiple
properties/sub-components to be referenced by name.

As an example, and at the risk of repeating posts from a few months
back, here are 2 simple queries:

     SELECT * FROM VEVENT WHERE
         ATTENDEE = "[email-masked]"
         AND ATTENDEE = "[email-masked]"

     SELECT * FROM VEVENT WHERE
         ATTENDEE = "[email-masked]"
         AND PARAM(ATTENDEE, PARTSTAT) = ACCEPTED

(there is not a single example in cap-07 that uses PARAM(), btw)

To a human, the meaning seems obvious; the first is asking for
all VEVENTS which are attended by the two specified CUs, the second
is asking for all events that a specified CU has accepted.

But CAP isn't parsed by humans, and the two queries have referred
to instances of the ATTENDEE property in different ways; the first
was referring to two _different_ ATTENDEEs, while the second was
referring to the _same_ ATTENDEE.

With the USING_PROPERTIES clause, the two queries could be
disambiguated as follows:

     SELECT * FROM VEVENT WHERE
         USING_PROPERTIES ATTENDEE my-att1, ATTENDEE my-att2
         WHERE my-att1 = "[email-masked]"
         AND my-att2 = "[email-masked]"

     SELECT * FROM VEVENT WHERE
         USING_PROPERTIES ATTENDEE my-att
         WHERE my-att = "[email-masked]"
         AND PARAM(my-att, PARTSTAT) = ACCEPTED

If the two clauses are 'tossed', they should be replaced with a clear,
unambiguous explanation of the meaning of querying a multi-instance
just by property name (i.e. does it mean 'any' instance of that property,
or 'all' instances of that property), rather than ignoring the issue
as SQL-MIN did.

It should also be noted that only 1 of the above queries could be
represented if the clauses were 'tossed' (we would have to choose
whether the two references to ATTENDEE in the first two examples
would refer to the same or different properties).

--Alan

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 13:55:57 -0500

At 04:05 PM 24/03/2002 -0800, Steve Mansour wrote:

>use of "USING_COMPONENT" seems like it's not buying us much. Seems like 
>this example could actually be shortened by writing it without the 
>USING_COMPONENT line:
>BEGIN:VQUERY
>EXPAND:TRUE
>"USING_COMPONENT".  Can someone describe the real value of this?  Or can 
>we drop it?   Same thing for "USING_PROPERTY".

Your rewritten query could be specifying a VEVENT which contains a
VALARM whose TRIGGER falls within a given time range, or a
VEVENT that contains multiple VALARMs, one of which has a TRIGGER
 >= '20000101T030405Z', and another VALARM which has
a TRIGGER <= '20001231T235959Z'.

I'm not sure which it does specify, as I can't remember offhand
the chosen interpretation, and can't find any text in cap-07 that
mentions this.

I would think the clearest interpretation would be for each reference
to VALARM to mean "any VALARM sub-component", in which case
USING_COMPONENT is necessary in the query (although perhaps a clearer
example could be found, or some explanatory text added).

--Alan

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 12:24:39 -0700

> or 'all' instances of that property), rather than ignoring the issue

We agree - lets clear up the text.

> would refer to the same or different properties).

In what case would 'two' ATTENDEEs be from the 'same' property?
ATTENDEE is a single valued, multiinstance property.

---

From: "Graham Gilmore" <[email-masked]>
Date: Mon, 25 Mar 2002 15:21:52 -0500

----- Original Message -----
From: "Doug Royer" <[email-masked]>
To: "CalSched IETF" <[email-masked]>
Cc: "CalSched IETF" <[email-masked]>
Sent: Monday, March 25, 2002 2:24 PM
Subject: Re: CAP draft 07 issues - sections 3 and 4

> ATTENDEE is a single valued, multiinstance property.

    Alan wasn't referring to two ATTENDEE values on the same property; he
was referring to two references to a single ATTENDEE property, as in this
example he gave:

    Notice that on the 2rd line of the above example, the property value is
referenced (the first ATTENDEE reference), and on the 3rd line, a parameter
of the property is referenced (the second ATTENDEE reference).  To reiterate
Alan's point, without the USING_PROPERTIES, it is ambiguous whether the
second ATTENDEE reference refers to the PARTSTAT parameter of same ATTENDEE
property referenced on the 2nd line or the PARTSTAT parameter of some other
ATTENDEE property.  This is disambiguated as follows:

    By naming the ATTENDEE property whose value = "[email-masked]" as
'my-att' on lines 2 & 3, we can be sure that the second reference (on line
4) refers to the same ATTENDEE property by using the name we've assigned.

    Graham

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 15:32:27 -0500

>ATTENDEE is a single valued, multiinstance property.

That's not what I was trying to say.

Perhaps an example would help; consider the following
snippet from an iCalendar object:

     BEGIN:VEVENT
     [...]
     ATTENDEE;PARTSTAT=NEEDS-ACTION:[email-masked]
     ATTENDEE;PARTSTAT=ACCEPTED:[email-masked]
     END:VEVENT

My point is that it's not clear whether the following query
would match that VEVENT or not:

You see the VEVENT contains an ATTENDEE whose value matches
"[email-masked]", and an ATTENDEE whose PARTSTAT matches
"ACCEPTED", so it would be considered a match if each time
the ATTENDEE property was used, it was taken to mean
"any ATTENDEE of the VEVENT".

--Alan

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 14:26:07 -0700

BEGIN:VEVENT
     [...]

When would you ever want it to match a value of one property, and parameter
of another property for the same property name?

---

From: Robert Lusardi <[email-masked]>
Date: Mon, 25 Mar 2002 16:28:32 -0500

I've been holding back my responses to this thread because I have not 
gotten to this section of CAP, but I can't hold back anymore ... I'm 
sorry if I'm stating something that's blatenly stated in the document.

As far as I've been following all the threads, CAP's query requests 
follow SQL. If that's true, then the examples that Alan uses are *not* 
ambiguous at all.

The use of AND in the statements means that the query below would fail. 
 If you wanted it to pass, then you would need an OR.

The example query with VALARM would *only* return VEVENTS whose alarm 
values were between those two dates. Again, not ambiguous at all.

As someone who is very familiar to SQL the use of USING_PROPERTY and 
USING PARAMETER are just needlessly confusing.

Is there something I'm missing?  If there's a point where CAP clearly 
breaks from SQL standard and this is stated in CAP (and this is  where 
USING_PROPERTY and USING_PARAMETER have been introduced), then again I 
apologize.  I will read through this section ASAP.

rob

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 16:49:49 -0500

I think what you're missing is that iCalendar's data model
is not that of a simple relational database.

The first attempt at a CAP query language made the assumption
that mapping iCalendar components and properties to SQL-92 tables
and columns was a simple problem, and went on to use SQL-92 to
query those 'virtual' tables and columns.

iCalendar's data model differs from this in these important
respects:

     1) A component may contain multiple sub-components (SQL-92
        tables may not have sub-tables).
     2) Multiple instances of the same property may exist within
        a component (a table may have only one instance of each
        column).

Searching through the archives at http://www.imc.org/ietf-calendar
will show that there has been much discussion on this, and as yet
no better workable suggestions.

No need to apologize, with this information in mind, we'd welcome
a cleaner, simpler way to query iCalendar's data model
without ambiguosity.

--Alan

At 04:28 PM 25/03/2002 -0500, Robert Lusardi wrote:
>gotten to this section of CAP, but I can't hold back anymore ... I'm sorry 
>if I'm stating something that's blatenly stated in the document.
>
>As far as I've been following all the threads, CAP's query requests follow 
>SQL. If that's true, then the examples that Alan uses are *not* ambiguous 
>at all.
>
>The use of AND in the statements means that the query below would fail. If 
>you wanted it to pass, then you would need an OR.
>
>As someone who is very familiar to SQL the use of USING_PROPERTY and USING 
>PARAMETER are just needlessly confusing.
>

---

From: [email-masked] (Steve Mansour)
Date: Mon, 25 Mar 2002 13:45:10 -0800

Pat?  You're driving this?
-Steve

...

---

From: Robert Lusardi <[email-masked]>
Date: Mon, 25 Mar 2002 17:09:48 -0500

> is not that of a simple relational database.

I'll definitely agree to that ...

>        tables may not have sub-tables). 

Not true (although this is really just a matter of semantics).  Take 
VEVENTS and VALARMS. You could have alarms that exist outside the realm 
of an event, but for our case alarms are "sub-components" of an event. 
 If alarms are implemented in a different table, then this table becomes 
a "sub-table" (I prefer "child table", but it doesn't matter), to the 
event table. The alarms only exist to the extent that the event exists.

>        a component (a table may have only one instance of each

Here I agree completely, especially in the case of a "simple" rdb. You 
could "overload" the column with multiple values and deliminters, but 
that's not really the point.  If this were the case though, the 
structure should have been designed as in 1) above.

> Searching through the archives at http://www.imc.org/ietf-calendar

This I need to do, but first finish CAP ...

> a cleaner, simpler way to query iCalendar's data model

Thanks :-)

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 17:34:17 -0500

At 05:09 PM 25/03/2002 -0500, Robert Lusardi wrote:
>VEVENTS and VALARMS. You could have alarms that exist outside the realm of 
>an event, but for our case alarms are "sub-components" of an event. If 
>alarms are implemented in a different table, then this table becomes a 
>"sub-table" (I prefer "child table", but it doesn't matter), to the event 
>table. The alarms only exist to the extent that the event exists.

That's true; Calendar could have been structured something like this.

However, a "child table" such as VALARM contains no column that allows
it to be joined with it's parent, in the way that an SQL child table
would probably contain it's parent's primary key.

Someone storing iCalendar in a relational DB would probably add in this
"parent id", but as it's not part of the iCalendar model, we can't query
on it in CAP-QL.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 16:38:34 -0700

> event table. The alarms only exist to the extent that the event exists.

Yes that is what we are doing in CAP-QL.

Components are virtual tables and their continued properties
are columns.

Properties are virtual tables and their parameters are columns.

These are somehow magically merged by the CS (out of scope for CAP)
by some implementation specific 'parent-id'.

We eliminated what we call cross-table joins. So it keeps the
model simple. That is I can say component.property, but not
component.propert.paramater.

We invented the PARAM() function to extract out parameters
from properties as the exception.

> structure should have been designed as in 1) above.

The effect is the same. Each virtual table exists for each property.
It really does not matter what the over the wire format is. If
component.property exists 4 times, it exists and the values are
unique in iCalendar, so it does not matter if the over the wire format
is  or is not flat. In this virtual db, the colum exists with 4
entries in the table for that property with the 'parent-id' all
the same.

As far as a query goes, x = value or it does not. x = condition or it
does not. We don't allow cross component joins in our virtual tables
(outside of the PARAM() function). And as the values are unique
to their scope, they could all exist in one virtual table and
the effect is the same for query for a given component.

For a query these are the same:

		PROPERTY:value1
		PROPERTY:value2

and

		PROPERTY:value1,valule2

Where both can be represented in the same virtual table as:

	a vitrtual COMPONET-table		

	prop-1-col		prop-2-col		PROPERTY-col
	----------		----------		-------------
	xxx			yyy			value1
							value2

There is NO case in iCalendar where those two could exists (even
if the ABNF allowed) where the values in the same component would
not be unique. Not when they are multi-instance, not when they
are multi-valued, not when both are allowed. The same query
can return all of the correct values. The CS is responsible
for makeing the over the wire format valid iCalendar format.

The same is true for contained components. They are unique
in the CS (but not perhaps on the wire). If you query for
them - they will be found. It does not matter if they
are both called VALARM or not. We do not allow cross component
joins, so you can not say where

	VALARM(#1) value [= < > ...condition] VALARAM(#2) value

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 18:48:25 -0500

You're asking that now, after agreeing to and typing the proposed
text that describes these clauses? That's not to say that we
shouldn't rethink whether CAP-QL needs this ability or not though.

I can think of reasons for wanting to query more than one
instance of a property name within the same object, but
the examples might seem a bit contrived. Also, all the queries
could be achieved by making multiple queries, and/or calls to
the CS, and/or filtering a larger returned data set in the CUA,
at the cost of performance.

If the consensus is that this ability is really not needed
within CAP-QL, then the USING_ clauses could be removed. Some
descriptive text would be needed to ensure that the example
I gave is not considered ambiguous though.

--Alan

---

From: Alan Davies <[email-masked]>
Date: Mon, 25 Mar 2002 19:27:12 -0500

>by some implementation specific 'parent-id'.

Yes, the implementation of properties/parameters is out of
scope for CAP, so how can we disallow something based on a
reason that we shouldn't know about because it's out of scope?

>component.propert.paramater.

I've no idea what you mean by that. We decided upon
PARAM(component.property, parameter) instead of
component.property.parameter as a point of syntactical
clarity and consistency; it's got nothing to do with any
of the issues we're discussing.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Mar 2002 18:09:19 -0700

Lets drop CAP-QL and go back to a SQL-MIN ~like~ plus 'IN'.

It means that the CUA has to do more work but it can
get all of the data. I just don't feel that ALL CUAs and
CS's are going to be able to implement all of this and
be compatible with each other. We are attempting to
invent a very complex query language and we expect CAP to
ship soon. I see these two goals as incompatible.

Lets go back to the basics and just have CAP do simple queries
where the CUA can get the data from the CS. Go back to
SQL-MIN plus add the 'IN' function. Then only allow ONE
logical operator where they MUST BE from the same component.

It will eliminate complex queries - but that seems to be
the large part of the debate.

Then we can tackle complex queries extensions as an add on draft.

---

From: Alan Davies <[email-masked]>
Date: Tue, 26 Mar 2002 10:59:17 -0500

Simplification sounds good, but how was SQL-MIN simpler than
CAP-QL?

We've been here before; CAP-QL grew out of pointing out the
inconsistencies and ambiguities in SQL-MIN.

SQL-MIN, as it existed in previous drafts, could _never_ have
worked; most examples that used it in the draft were totally
ambiguous.

If we're going to simplify something, simplify CAP-QL, which
at least has a chance of being understood by a machine, not
just a human who glances at it and thinks that it sort of
looks correct.

--Alan

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 Mar 2002 10:12:24 -0700

> just a human who glances at it and thinks that it sort of

I am happy with that. My issues are for PDA, Cell, and limited
memory support:

	(1) Currently we allow unlimited logical operators. I mean I
             could create a query that was 90 pages long used 100
             USING statements an 40 levels of parentheses and still
             add to it.

	(2) We need some way to for a CS to say that it can not
	    handle more than (example) 2 logical operators where
             both are from the same instance of the same component.

	(3) I think we are turning the CS into a database server.
	    And that is going to make writing a CS near impossible.
             Like XML-Schema - it is complete -  but who can write
             a complete one?

         (4) Is a vendor really going to make a CUA GUI that allows the
             CU to ask for all appointments where 'fred' is an attendee
             and no one else has accepted? And any other variation
             of that? Does this need to be a query to the CS, or can
             we limit the queries to something simple like:

		SELECT * FROM VEVENT WHERE ATTENDEE = 'fred'

             then let the CUA sort it out what it wants?

             I think we have pushed the CUA code into the CS by
             forcing the CS to get 'what ever I want'. And I think the
             correct mode should be 'get what I need so I can do
             what I want'.

Perhaps the best break point would be that a MIN version could
not support any USING operators. This would limit the queries
and force the CUA to do more data processing. But at the same time
allows small CS's to be implemented. Also - MIN would not allow
any parentheses at all. And a limited number of logical operators.
Then the FULL QL could be what CAP-QL is now for and allow a mega-CS.

Maybe define some pre-defined queries that take an argument as
John has pointed out. Get 'today', get everything that changed
since last sync, all non-booked entries, ...

I have already mapped most of CAP-QL into SQL (somewhat tested).
My concern is that we are forcing all CS's to be rather huge
implementations that might take a LONG time to be interoperable.