[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6.1.1 CAL-QUERY Value Type
Andrea wrote on 10/23/2002 03:33:10 PM:
> sorry I can't find a proper proposal for this (though I mentioned
it in
> I mentioned it in <20020906134355.GF32393@xxxxxxx>), but since
it's an
> obvious error, I propose to fix it right now.
>
>
> Rules 6 and he example have the syntax component.*:
>
> SELECT VALARM.* FROM VEVENT WHERE UID = "123"
>
> But the ABNF doesn't allow this.
Correct. Given that the example
used is a fairly common one Id say the ABNF needs some changing.
> IMHO it should be something like:
>
> cap-col = ;
Any property name found in the component
>
; named in the comp-name used in the "FROM" clause.
>
;
>
; SELECT ORGANIZER FROM VEVENT ...
>
;
>
; OR
>
;
>
; A component name of an existing component contained
>
; inside of the comp-name used in the "FROM" clause.
>
;
>
; SELECT VALARM FROM VEVENT ...
>
;
>
; OR
>
;
>
; Any property name found in any component contained
>
; inside of the comp-name used in the "FROM" clause;
the
>
; component and property name are separated by a dot '.'
>
;
>
; SELECT * FROM VEVENT WHERE VALARM.TRIGGER < '20020201T000000Z'
In looking at the changetext you proposed
I notice that there is still no 'terminal' values for the cap-col ABNF
entry, only text. I do not think this is legal. I expect that
the ABNF needs to be formatted like:
cap-col
= ; Any property name found in the component
; named in the comp-name used in the "FROM" clause.
;
; SELECT ORGANIZER FROM VEVENT ...
( cap-col-prop /
; OR
;
; A component name of an existing component contained
; inside of the comp-name used in the "FROM" clause.
;
; SELECT VALARM FROM VEVENT ...
cap-col-prop2
cap-col-prop
= eventprop ;Legal properties for a "VEVENT".
cap-col-prop2
= ( eventprop / alarmc ) ;Legal properties and contained
; objects for a "VEVENT"
.
cap-col-prop
/= todoprop ;Legal properties for a "VTODO".
cap-col-prop2
/= ( todoprop / alarmc ) ;Legal properties and contained
; objects for a "VTODO"
.
...
Where we use the "/=" ABNF
notation to restrict what properties are usable when. In the case
above Ive restricted the cap-col values for a VEVENT to be just those eventprop
values defined in RFC 2445. Yes, doing this will cause ABNF to get
more complex but it will allow us to avoid any crocks like the one you
described (plus I dont think we can have a dangling ABNF like we do now).
My ABNF crafting on the fly is not so
great but I think the intent is at least clear enough. We can get
a ANBF guru to tune it as appropriate if we decide to make it work right.
> However, AFAIK we never discussed this before,
so we might want to fix
> this it later on.
Actually I raised this at the IETF in
February/March in hallway talks w/Steve & the Steltor contingant. Guess
it didnt get reflected in any changes since then. I think that we
need to be able to do as you noted in the initial version of the protocol
since its a very common thing to want to do.
Bruce
===========================================================================
Bruce Kahn
INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration
Phone: 978.399.6496
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...