Subject: CAL-QUERY definition

From: Andrea Campi <[email-masked]>
Date: Tue, 16 Jul 2002 19:14:17 +0200

Hi all,

there's something I don't understand in the definition of CAL-QUERY.

 - cauprops and capcprops are used but not defined anywhere. They
look like they have no purpose either; maybe they are leftovers
from a previous revision?

 - uprop-list and cprop-list are defined but not used?

 - cap-local, what purpose does it serve? Its description mentions
cap-using but that's not defined anywhere.

 - cap-colval is the only thing which can appear on the left side
of a cap-oper, but it doesn't include STATE() etc. This doesn't
look right and goes against the examples (or I am missing something).
In addition, it accepts cap-ucolq which isn't defined.

 -       cap-factor  = cap-colval SP cap-oper SP col-value
                  / cap-colval SP "NOT LIKE" SP col-value
                  / cap-colval SP "LIKE" SP col-value
                  / cap-colval SP "IS NULL"
                  / cap-colval SP "IS NOT NULL"
                  / col-value SP "NOT IN" cap-colval"
                  / col-value SP "IN" cap-colval"

 There are extra double quotes at end of the last two lines.

 - [NOT] OWNER() is not allowed anywhere - should it be, or should
it just be moved to UPN-FILTER?

Also, I don't think the definition allows for component.property
syntax (but I might be completely wrong here).

A couple of suggestions:

 - it could be a good idea to explicitely state that AND, OR etc
are case sensitive and MUST be spelled in capital letters. This is
apparent from the draft but we all know the devil is in the details...

 - PARAM() could use at least a short paragraph like the other
functions

 - literal-data definition talks about value types, but I think it
could be beneficial to state that enumerated types are equivalent
to strings. Otherwise you wouldn't be able to say:

     TRANSP='OPAQUE'

A final note: I hate the mismatch between '=' and '!='. It should
either be '=' and '<>' as in SQL, or '==' and '!=' as in C.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Jul 2002 13:24:20 -0600

> cap-using but that's not defined anywhere.

They may have been left over from a previous edit - thanks - looking.

> In addition, it accepts cap-ucolq which isn't defined.

Looks as if this needs more editing :-)

I'll spend some time this weekend and go through that in detail
and send the new section to the list for editorial review.

>  There are extra double quotes at end of the last two lines.

Thanks I just remove them.

> it just be moved to UPN-FILTER?

No, it should also be allowed in the query as in,

	SELECT * FROM vevent WHERE ORGANIZER = OWNER()

I'll update the ABNF, thanks for finding that.

> apparent from the draft but we all know the devil is in the details...

They are not case sensitive - all of iCalendar is case in-sensitive.
Do we need to add a note to CAP for this? Or is that it is already
defined in 2445 sufficient?

>  - PARAM() could use at least a short paragraph like the other

Yep - I'll add a section. 

> to strings. Otherwise you wouldn't be able to say:

Another great find - thanks.

> either be '=' and '<>' as in SQL, or '==' and '!=' as in C.

Good point, if there are no objections, I'll change any '!='
to '<>'.

---

From: John Stracke <[email-masked]>
Date: Tue, 16 Jul 2002 16:00:22 -0400

>They are not case sensitive - all of iCalendar is case in-sensitive.
Actually, no, it's not.  From 2445:

   All names of properties, property parameters, enumerated property
   values and property parameter values are case-insensitive. However,
   all other property values are case-sensitive, unless otherwise
   stated.

-- 
/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|This is the .sig that says... Ni!                       |
\========================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Jul 2002 16:28:27 -0600

"G. Barnes" wrote:
> 
> While reading the latest CAP draft, I noticed the bibliography
> didn't match completely with the references in the text.  This isn't
> surprising in a draft, so I did a little work which hopefully someone
> can use to make the bibliography/references more useful.
> 
> Here are my notes, which hopefully are self-explanatory:
> ...

VERY helpful - THANKS!

-Doug

---

From: "G. Barnes" <[email-masked]>
Date: Tue, 16 Jul 2002 15:10:42 -0700 (PDT)

--------------------------------------------------------
Text abbreviation different from bibliographic abbreviation

In text:   [BEEP] (numerous places)
In bibliography: [RFC3080]

text:  [MIME] (numerous places)
bib:   [RFC2045]

text:  [BEEPTCP] (p21)
bib:   [RFC3081]

text:  [SASL] (p23)
bib:   [RFC2222]

text:  [SQL92] (p32)
bib:   [SQL]

text:  [RFC396] (p9)
bib:   [RFC2396]
   Note:  2396 is correct

--------------------------------------------------------
in text, but not in bibliography
   [GUIDE] (p5)  --- I think this is RFC 3283, Guide to Internet Calendaring
   [RFC2718] (p9) --- Guidelines for new URL Schemes
   [RFC 2459] (p24) --- Internet X.509 Public Key Infrastructure
                        Certificate and CRL Profile (obsoleted by RFC3280)
   [RFC 2278] (p57) --- IANA Charset Registration Procedures (obsoleted by
                        RFC 2978)
   [RFC 2277] (p58) --- IETF Policy on Character Sets and Languages

--------------------------------------------------------
in bibliography, but not in text:
   [RFC1521] Borenstein, N., Freed, N., "Specifying and Describing the
             Format of Internet Message Bodies", RFC 1521, September 1993
             ftp://ftp.isi.edu/in-notes/rfc1521.txt

   [RFC2246] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0",
             RFC 2246, January 1999
             ftp://ftp.isi.edu/in-notes/rfc2246.txt

   [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
             Locators", RFC 2392, August 1998
             ftp://ftp.isi.edu/in-notes/rfc2392.txt

   [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.1"
             http://www.unicode.org/unicode/standard/standard.html

   [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
              Information Interchange, ANSI X3.4-1986.

   [CharEncoding] "Worldwide Character Encoding -- Version 1.0",
             Addison-Wesley, Volume 1, 1991, Volume 2, 1992.
             UTF-8 is described in Unicode Technical Report #4.
--------------------------------------------------------

			Greg Barnes
			Computing and Communications, University of Washington
			[email-masked]
			(206) 685-3295

---

From: Andrea Campi <[email-masked]>
Date: Wed, 17 Jul 2002 10:09:51 +0200

> > there's something I don't understand in the definition of CAL-QUERY.
[...]
> They may have been left over from a previous edit - thanks - looking.
[...]

Great, thanks.

While I was writing the text below, I noticed formal definitions for
ENABLE Parameter (6.2.1) and LOCAL Parameter (6.2.2) are incorrect
(copy and past-o :-?). Also, there's a typo (Format Definition instead
of Formal) all over the draft.

Also, ALLOW-CONFLICT property doesn't specify the default in case no
ALLOW-CONFLICT is present.

I'd like to suggest a couple of parameters for QUERYID (I am open to
suggestions for the names):

 NAMESPACE Parameter

	Parameter Name: NAMESPACE

	Purpose: This parameter qualifies the QUERYID as belonging to
a particular namespace.

	Value Type: TEXT

	Conformance: This property MAY be specified in the "QUERID"
properties.

	Description: CAP server implementation may choose to qualify
queries as belonging to a namespace. Namespaces are completely
separated from one another, so that queries with the same name but
different names can coexist.

	This allows a client to install stored queries in a server
without worrying about name conflicts.

	This parameter is less useful for non-stored queries but may
be specified for documentation purpose.

	Formal Definition: The parameter is defined by the following
notation:

	namespace	= "NAMESPACE" ":" text

	Example: The following is an example of two different stored
queries with the same QUERYID in the same namespace. They could both
exist in the same CAP server as they don't conflict with each other.

	BEGIN:VQUERY
	QUERYID;NAMESPACE=example.net:A query
	END:VQUERY

	BEGIN:VQUERY
	QUERYID;NAMESPACE=example.com:A query
	END:VQUERY

 NATIVE Parameter

	Parameter Name: NATIVE

	Purpose: This parameter qualifies the QUERY as having an
implementation known only to the server and not necessarily mappable
to a CAL-QL-1.

	Value Type: BOOLEAN

	Conformance: This property MAY be specified in the "QUERID"
properties for stored queries.

	Description: A server may choose to implement some stored
queries in the most efficient way, which may not be easy to express
in CAL-QL-1. A server may also choose to do this in order to avoid
having to parse and compile CAL-QL-1 queries in its native query
language.

	This parameter allows a server to mark queries as having
a native implementation, so a client can't expect to know how the
query works. However, the client can still ask the server to run
the query if it knows what it returns. This can be thought as the
equivalence of encapsulation in object oriented parlance.

	The parameter defaults to FALSE

	Formal Definition: The parameter is defined by the following
notation:

	native	= "NATIVE" ":" boolean

I also propose to change VQUERY to allow a VERSION property. This
allows a future draft to define extensions to the query language
while keeping backward and forward compatibility.

If you agree to this, then I think we should discuss whether or
not the QUERY-LEVEL should allow for a list.
To give you an example of what I'm talking about, let's say a future
draft defines substitution parameters in stored queries, so that
for instance it's possible to store (this is just an example!):

	BEGIN:VQUERY
	QUERYID;NAMESPACE=example.com:foo(date)
	QUERY:SELECT * FROM VEVENT WHERE DTSTART = ?date?
	END:VQUERY

	which would be then invoked as:

	BEGIN:VCALENDAR
	VERSION:2.0
	CMD:QUERY
	TARGET:relcal1
	BEGIN:VQUERY
	QUERYID;NAMESPACE=example.com:foo('20020708T000000Z')
	END:VQUERY

This could be name CAL-QL-EXT1. At a later time a new draft could
specify CAL-QL-EXT2, which doesn't imply CAL-QL-EXT1. It would be
most useful to be able to say:

	...
	BEGIN:VREPLY
	...
	QUERY-LEVEL:CAL-QL-1,CAL-QL-EXT2,my-extensions
	...
	END:VREPLY

Wow, it's a lot of proposals at a time!
What do you say?

Bye,
	andrea

---

From: Doug Royer <[email-masked]>
Date: Sat, 20 Jul 2002 13:50:42 -0600

> of Formal) all over the draft.

I just updated the draft - thanks.

> ALLOW-CONFLICT is present.

The ALLOW-CONFLICT property is only used in a VCALSTORE and VAGENDA
and MUST BE specified once. So no default is needed.

---

From: Doug Royer <[email-masked]>
Date: Sat, 20 Jul 2002 14:12:03 -0600

"G. Barnes" wrote:

Thanks - I have updated the draft.