Subject: SKiCal ABNF Quirk

From: [email-masked]
Date: Wed, 6 Sep 2000 22:36:15 -0400

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: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 8 Sep 2000 14:28:23 +0200

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:

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.

Bruce

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 08 Sep 2000 15:51:14 +0200

>                        "REFERENCED" ; Not present at the event

As written, a Personroleparam can only have the value
DIPROLE=<any 
text>PERFORMERCREATORCOMPOSERCONDUCTORARTISTEDITORPRODUCERGUIDESPEAKERCHAIRPRESENTREFERENCEDINVITED, 
which is probably not what was intended.

If you want the examples to be examples, put a semicolon to the left of them.
If you don't, they are part of the grammar - and putting items one after 
the other means that they are concatenated, not that they are alternatives.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 8 Sep 2000 17:20:45 +0200

So I guess we were trying to describe the ultimate polymath:-)

Thanks for the correction - we will get to that right away.

Greg

As written, a Personroleparam can only have the value
DIPROLE=<any
text>PERFORMERCREATORCOMPOSERCONDUCTORARTISTEDITORPRODUCERGUIDESPEAKERCHAIRP
RESENTREFERENCEDINVITED,
which is probably not what was intended.

If you want the examples to be examples, put a semicolon to the left of
them.
If you don't, they are part of the grammar - and putting items one after
the other means that they are concatenated, not that they are alternatives.

---

From: Federico Mena Quintero <[email-masked]>
Date: Fri, 8 Sep 2000 16:15:46 -0400

> codifications and restraints.  SKiCal has to be more permissive

Is it just me, or does anyone else think SKiCal is severe overkill?

What is wrong with just using a VEVENT component with

	SUMMARY: Pink Panther Philarmonic weekly concert
	DTSTART: <some Friday in the evening, of course>
	DTEND: <two hours after that>
	LOCATION: Pink Symphony Hall, 69 Some Street, Anytown, Anywhere
	DESCRIPTION: This week Inspector Clouseau himself conducts the
	 renowned Pink Panther Philarmonic with a spectacular and loud
	 programme with works by Bartók, Stravinski and Shostakovich.
	URL: http://www.pinkpantherphilarmonic.org/friday.html

If you try to classify every possible public concert/conference/
exhibition/whatever, you'll end up with yet another inconsistent RFC
just as thick as iTIP and iCalendar.

Sorry for sounding bitter, but it sounds like people are proposing
lots of stuff that nobody will ever implement.

  Federico

---

From: Pär Lannerö <[email-masked]>
Date: Fri, 08 Sep 2000 22:32:10 +0200

> Is it just me, or does anyone else think SKiCal is severe overkill?
[...]
> lots of stuff that nobody will ever implement.

Actually my company and a few others in Scandinavia have implemented
large parts of SKICal in several systems, and customers are eager to get
a way to exchange event information more detailed than what is possible
using RFC2445 without extensions. Why not standardize the most commonly
needed extensions? (Price, Where to get tickets, Handicap facilities...)

For sure, not many applications will make use of _all_ extensions, but
the more that gets specified in a publicly available document, the less
people will need to use their own proprietary extensions, and the more
useful the information published on iCalendar/SKICal format will be.

/Pär

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Mon, 11 Sep 2000 12:07:27 +0200

Well nothing is "wrong" with doing what you have suggested below.  And
(liberally interpreting your generalizations) this is a valid SKiCal
representation.  But take a look out there on the Internet and you will see
that there is a large, dynamic event marketplace, where various
infomediarias are creating vertical sectors (walled gardens) with
proprietary schemas.

Now you either believe in end-to-end market solutions or you don't.  I for
one do.  And proof that I am not alone on this is everywhere.  For example
take a look at the recently launched

http://www.uddi.org/

It will be up to event publishers how much structure they desire in their
postings.  By reducing obligatory fields to a minimum we are giving them
that choice.  If structure creates efficiency - I believe it will be used.
It certainly is the case in this country (Sweden) and I suspect that as
other countries approach Scandinavia in (specially wireless) internet access
the need for tighter structure and discovery efficiency will become more
apparent.  I suggest it is a good time to get started.

btw  sounds like a fun concert:-)

Fredrico's example

  But you have missed the point.