Subject: Re: (#2) 4.1.1 Grammar for Search Mechanism

From: [email-masked]
Date: Mon, 28 Jan 2002 11:22:45 -0500

Doug proposed:
>  (6) A contained component without a '.' it is the same as
>      <component>.* with the result being a properly formatted
>      <component>(s) in the data stream, and correctly formatted
>      in the contained component(s) in iCalendar (RFC2445) format.
[Snip, snip]
>                (b) SELECT VEVENT.VALARM FROM VEVENT
>
>                (c) SELECT VALARM FROM VEVENT
>
>                (d) SELECT VEVENT.* FROM VEVENT
[Snip, snip]
>                      That (b), (c), and (d) yield the same results.
>                      And that is select all VALARMS from all VEVENTS.

Hmm, I was following this up until that last bit but I disagree w/it.  (b) 
and (c) are equivalent but (d) is not.  I see (d) as returning all 
properties of the VEVENT AND any associated VALARMs contained on the 
VEVENT.  That means that the ATTENDEE list, SUMMARY, DTSTART, etc of the 
VEVENT are also returned, not just the contained VALARM.  Or am I just 
misreading the text for (6) somehow??

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 29 Jan 2002 11:37:12 -0500

Doug wrote:
>      (2) ABNF is tricky stuff - PLEASE REVIEW.

Well, I did find 1 small glitch in at least one part of the ABNF:

    cap-cmp-rhs = ( cap-oper col-literal
                  / "IS NULL" )
                  / "IS NOT NULL"
                  / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                             # Wildcard characters may
                                             # be used in col-literal

has mismatching parens.  I believe it should just be:

    cap-cmp-rhs = ( cap-oper col-literal
                  / "IS NULL" 
                  / "IS NOT NULL"
                  / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                             # Wildcard characters may
                                             # be used in col-literal

otherwise you're gonna get some funky querys...

Also, should cmp-oper actually be cap-oper?  I cant find cmp-oper used in 
any ABNF nor can I find cap-oper defined in the ABNF...

Bruce

---

From: [email-masked]
Date: Tue, 29 Jan 2002 11:50:04 -0500

>      (2) ABNF is tricky stuff - PLEASE REVIEW.

There _may_ be a small problem w/the ABNF snippet:

    cap-cols    = ( cap-col / cap-col "," cap-cols )
                  / "*"

It may or may not be what you want, depending on the answer to this:  Is 
it correct / valid / acceptable to have a query like:

        SELECT VALARM,DTSTART,DTEND,UID,* FROM VEVENT

According to the ABNF, this is strictly legal (the last instance of a 
cap-cols instances as "*" instead of cap-col) but Im not sure thats what 
you wanted since it has the side effect of making the rest of the values 
superfluous/redundant.  After all, why say give me "DTSTART, DTEND and 
_all_ the properties of the VEVENT" when the 1st 2 phrases are just 
clutter...

If this is NOT what you wanted then you need to define cap-cols more like 
(and this is not 100% baked but you get the idea):

        cap-cols        = cap-col-wildcard / cap-col-explicit
        cap-col-explicit = ( cap-col / cap-col "," cap-col-explicit )
        cap-col-wildcard = "*"

Bruce

---

From: [email-masked]
Date: Tue, 29 Jan 2002 12:01:17 -0500

One more ABNF comment for now.  Given the ABNF:

    cap-col     = # Any property name found in the component
                  # named in the comp-tbl used in the FROM clause.
                  #
                  #   SELECT ORGANIZER FROM VEVENT ...
                                   #
                  # OR
                  #
                  # A component name of an existing component contained
                  # inside of the cmp-tbl used in the FROM clause.
                  #
                  #   SELECT VALARM FROM VEVENT ...

then it appears as if (corrected) example (f):

                (f) SELECT * FROM VEVENT WHERE
                     VALARM.TRIGGER < 20020201T000000Z
                     AND VALARM.TRIGGER > 20020101T000000Z

is not allowed.  The "OR" part says "existing component contained" so that precludes accessing / referencing the property values (or 
property parameter values) of the contained components.  The prose needs 
to be adjusted to allow this.

Bruce

---

From: [email-masked]
Date: Tue, 29 Jan 2002 11:55:41 -0500

Yet another ANBF comment.  I think the ABNF is not complete (or 
technically a valid ABNF) due definitions like:

    cap-col     = # Any property name found in the component
                  # named in the comp-tbl used in the FROM clause.
                  #
                  #   SELECT ORGANIZER FROM VEVENT ...
                                   #
                  # OR
                  #
                  # A component name of an existing component contained
                  # inside of the cmp-tbl used in the FROM clause.
                  #
                  #   SELECT VALARM FROM VEVENT ...
[Snip]
    cap-local   = # Any string that is composed of the characters 
                  # that could be a cap-col name, but is not any
                  # cap-col name. It is suggested that the
                  # string start with "x-" to ensure it does not
                  # conflict with any existing or future cap-col name.
                  # This name MUST BE defined in the cap-using and
                  # can only be used in cap-cmps of the same query.
                  # And this name is only known and valid for the
                  # provided query and only for the lifetime of
                  # the query.

and so forth.  The ABNF MUST contain terminals for all definitions (or 
weasle out and say "See RFC xxxx" for the ABNF for a URI" like we did in 
RFC 2445 so we did not have to include their ABNF in our RFCs).  Otherwise 
its simply not possible to build an ABNF that can be parsed and validated 
for correctness / conflicts / accuracy. 

The solution is to keep the current prose and simply put in the ABNF 
elements that the prose is describing.  When ti comes to "either ... 
or..." cases then the standard ABNF formatting is used.

Its not always simple but it is a must for the ABNF to be of any use at 
all.

Bruce

---

From: [email-masked]
Date: Tue, 29 Jan 2002 12:16:14 -0500

Patrice Lapierre thoughtfully replied on 01/28/2002 11:24:03 AM:
> > Just how are property parameters (ie: PART-STAT=Declined, 
> > X-LDC-BLECH=ALWAYS or SENT-BY="mailto:[email-masked]") to be 
organized / 
> > treated? 
>
> The proposition includes the PARAM() function for this purpose:
> 
> e.g.,
> 
>    SELECT * FROM VEVENT 
>    USING_PROPERTIES ATTENDEE att
>    WHERE PARAM( att, 'PARTSTAT' ) = 'DECLINED'

(I reordered the quoting for readability).  I dont want to assume anything 
so Ill check w/the WG; Is using the last form of the ABNF:

    capselect  = ( "SELECT" " " cap-cols " "
                   "FROM"   " " cap-tbl " "
                        "WHERE"  " " cap-cmps

                 / "SELECT" " " cap-cols " "
                   "FROM"   " " cap-tbl

                 / "SELECT  " " cap-cols " "
                   "FROM"   " " cap-tbl  " "
                   "USING_PROPERTIES" " " cap-col cap-local
                   "WHERE"  " " cap-cmps )

required when using PARAM(..) in a query?  Its not expressly stated so its 
very unclear of the linkage between the "USING_PROPERTIES" version and 
when I can or cannot use PARAM(..).

If it is not required then is USING_PROPERTIES really necessary?  Couldnt 
we just simplfy the last term of the ABNF to into the 1st?  We could even 
further simplify the ABNF, using optional bracketing for capselect to 
something like:

    capselect  = ( "SELECT" " " cap-cols " "
                   "FROM"   " " cap-tbl [ " " 
                   [ "USING_PROPERTIES" " " cap-col cap-local " " ]
                         "WHERE"  " " cap-cmps ] 

If it is required then some prose to that effect needs to be added (at 
least to the proposal as it was posted).  However I dont see any need for 
mandating it.  Its not clear why the given example could not be simplified 
down to:

    SELECT * FROM VEVENT 
    WHERE PARAM( ATTENDEE , 'PARTSTAT' ) = 'DECLINED'

Finally, is the prose for PARAM() left out because its part of the current 
drat but in a different section or was it accidentally left undescribed to 
generate traffic?? :^)

Bruce
PS: If we dont simplify the ABNF down, then you need to add a missing " " 
at the end of the current "USING_PROPERTIES" line!)
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 29 Jan 2002 12:21:44 -0500

One last ABNF comment for now.  This ABNF:

    cap-cmp     = ( cap-ucol cap-cmd-rhs
                  / cap-ucol cap-oper cap-literal
                  / "PARAM(" cap-col "," cap-param ")" cap-cmp-rhs
                                   / "CONTAINS(" cap-col "," col-literal 
")"
                  / cap-logical
[Snip]
    cap-cmp-rhs = ( cap-oper col-literal
                  / "IS NULL" )
                  / "IS NOT NULL"
                  / "LIKE" " " col-literal ) # Where the SQL '%' and '_'
                                             # Wildcard characters may
                                             # be used in col-literal

seems to be a bit redundant.  In particular, the first 2 parts of cap-cmp 
resolve to a sub and superset so why have the subset at all?  Expansion of 
the 1st 2 terms becomes:

    cap-cmp     = ( cap-ucol ( cap-oper col-literal
                        / "IS NULL" )
                        / "IS NOT NULL"
                        / "LIKE" " " col-literal )
                  / cap-ucol cap-oper cap-literal

which can simplified down to:

    cap-cmp     = ( cap-ucol ( cap-oper col-literal
                        / "IS NULL" )
                        / "IS NOT NULL"
                        / "LIKE" " " col-literal )

or just:

    cap-cmp     = ( cap-ucol cap-cmd-rhs

basically (I left off the last 2 lines of the original ABNF for clarity). 
Am I missing something or can we simplify the ABNF down??

Bruce

---

From: Alan Davies <[email-masked]>
Date: Tue, 29 Jan 2002 12:45:35 -0500

>when I can or cannot use PARAM(..).

USING_PROPERTIES is nothing to do with PARAM().

>                   [ "USING_PROPERTIES" " " cap-col cap-local " " ]

That's an alternative and perhaps clearer layout.

>drat but in a different section or was it accidentally left undescribed to 

It's in Doug's most recent revision (#3).

--Alan

---

From: [email-masked]
Date: Tue, 29 Jan 2002 14:04:06 -0500

> USING_PROPERTIES is nothing to do with PARAM().

Thanks for clarifying that. 

It should be stated that there is NO text about USING_PROPERTIES in the #2 
proposal that I can find.  Only the ABNF has it but w/o any description or 
text.  Perhaps it should be renamed so as to NOT imply property parameters 
(given the cited examples it can easily be mistakenly inferred like I 
did.).  Hint, hint...

> It's in Doug's most recent revision (#3).

I got a note from Doug saying that all my postings were out of date and 
that #3 had been posted on Sunday PM (and a #4 will result of the apparent 
traffic on #3).  I havent seen 'em yet (nor have I gotten my own back yet) 
so Ill have to recheck w/Paul H. about it.  He reported lots of problems 
last week due to the IBM changeover going on but I thought they were 
resolved by now.

Ill try to do a web search of the IMC archives and catch up but given I 
saw no traffic on the ABNF in #2 I suspect many of my ABNF related 
postings are still relevant.

Bruce