SV: SKiCal ABNF Quirk

["Greg FitzPatrick" <greg.fitzpatrick@xxxxxxxxxxxxx>]

Bruce

I am no ABNF guru either.  I think we did the correct thing, but I would
look forward to further comment here.

Since we are on this subject, I would like to say a few things in
relationship to this, which though not having bearing on the SKiCal RFC
status, I believe might be of general interest.

When I have suggested the feasibility of having Namespaces in mime
directories (perhaps even an I-D to that effect), the reply is often that we
already have that taken care of - courtesy of iana-tokens.

What we are looking for in the long run is the use of multiple schemas
designated by namespaces in event objects.  These schemas could exist at the
property level, the property parameter level, and the property and property
parameter value level.

Offhand I could envision how a mime-directory object and an XML object could
reference the same schemas and typing constraints, though our friend Graham
Klyne might have to develop a schema-content-negotiation protocol to make
this work:-).

Since iCal addresses a considerably narrower scope of terminologies than
SKiCal, we have the luxury with iCal of being more "severe" in our
codifications and restraints.  SKiCal has to be more permissive

At the same time any discovery process on SKiCal objects to be effective
will be dependent on "naming markets", where event publishers can choose
amongst taxonomies and specific terms which are in-tune with the market.
These naming markets will have to be dynamic and timely.



In our draft we have tried to show that it is not feasible for us to be
"severe" with the possible ROLE values for PERSONS, THINGS and THINKS and
indicated our belief that mechanisms will evolve in the near future
comparable to the namespaces-schemas-types within the XML sphere.


Greg

PS if any one believes that the iana process suffices as it is, then I would
suggest that somebody build an XML schema bridge for it.


Bruce:

Ok, Ill admit Im no ABNF guru but I think the ABNF in the draft needs to be
changed to be 'proper'.  The format does not quite seem normal based on my
limited RFC 2445-2447 ABNF exposure but Ill see if I can put my finger on
it.  In the SKiCal draft the first example is:

     Personroleparam  = "DIPROLE" "=" text
                      ; It is RECOMMENDED that the text value be
                      ; chosen from a list, as described in section 4
                      ; of this memo. One example of such a list is
                      ; given here:

                       "PERFORMER"  ; Appearing at the event
                       "CREATOR"    ; Not necessarily present
                       "COMPOSER"
                       "CONDUCTOR"
                       "ARTIST"
                       "EDITOR"
                       "PRODUCER"
                       "GUIDE"
                       "SPEAKER"
                       "CHAIR"
                       "PRESENT"    ; At the event
                       "REFERENCED" ; Not present at the event
                       "INVITED"

A comperable one from RFC 2445 is:

     cutypeparam        = "CUTYPE" "="
                        ("INDIVIDUAL"          ; An individual
                       / "GROUP"               ; A group of individuals
                       / "RESOURCE"            ; A physical resource
                       / "ROOM"                ; A room resource
                       / "UNKNOWN"             ; Otherwise not known
                       / x-name                ; Experimental type
                       / iana-token)           ; Other IANA registered
                                               ; type
    ; Default is INDIVIDUAL

The SKiCal examples' first line defines the value as 'text' but then it goes
on to explain more and give some explicit values.  The iCalendar example
lists the codified values and then "leaves it open" by allowing "x-name" and
"iana-token" values which are previously defined as essentially "text".  So,
either SKiCal is using a slightly different but allowable ABNF format or the
ABNF needs to be slightly changed to style shown above.

Can some ABNF Guru please comment on this??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...