Subject: mixing mimedirectiory ABNF and XML

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 18 Jul 2001 15:36:59 +0200

I have a question to the list.

For some time now the SkiCal group has been working on our “Opening
Times” properties.  In the updated draft v.04 you can see how we solved
some of the problems involved, using primarily property parameters.

It is now apparent to us that the best solution is to forgo property or
property parameter constructions and put together the Opening Times
package using value types.  I assume this is also what happened to Frank
et al some years back when trying to put together the iCal Reoccurrence
set. 

The authors of 2445 probably found that the logical models possible
using properties and property parameters were not sufficient, so they
used value-types with their own syntax logic.  As delimiters between
those value-types, they  reused the colon, semicolon and equal sign.  

I remember when first reading 2445 that it took a while to understand
that the Reoccurrence set was  a property value and not a construct of
properties and property parameters.

Now we are doing the same.  There is an ABNF snippet of such a property
value-type declaration included below and as you can see we are using
“(“ and “,” as separators.  But please don't get involved in picking
apart the snippet, since it is not the purpose of this message.  

During our work it struck us that since a Property value could be formed
pretty much any way we wished, why create a new syntax when XML already
exists.  Why not use an XML DTD or Schema declaration for our
“optimeset” property value.

Instead of creating this 

optimeset  =  ”OPTIMESET “=” “(”  (optimeparam) ”)”

we could do this

optimeset  =  “<” ”OPTIMESET” “>” optimemaram

so that an object might look like this...

DTOPEN;language=”XML1.0”:
<OPTIMESET ID =”123”>
<OPTERM>20020101/20021231</OPTERM>
</OPTIMESET>

instead of this…

DTOPEN;language=”something Niklas made up”:
OPTIMESET;ID=123(OPTERM=20020101/20021231)

           *** Note: the language parameter is used in jest

Basically we would be using an ABNF to describe what was actually a DTD
or SCHEMA. This seems rather unconventional.

Combining an XML value type with iCal Mime-directory has  many positive
outcomes.  It means that we can reuse the same DTD/SCHEMA in our XML/RDF
calendaring work as for our iCal extension, we can adhere to an
acknowledged standard, we can use any number of validating tools to help
us when designing and our logical model comes to a great extent
ready-made. 
   
We would like to get some opinion on this.  Do angle brackets in SkiCal
value-types cause allergic (or kneejerkic) reactions for anyone?

Though it is possible to define the DTD/SCHEMAS in ABNF it would
certainly save effort to do them in their natural habitat. Would ABNF
and XML-SCHEMA in the same RFC be problematic?  Would we have to define
the optimeset as an XML-SCHEMA in a separate draft and then refer to it?

Love to hear some opinion on this?

Greg

optimeset  =  ”OPTIMESET=(”  (optimeparam) ”)”

optimeparam  =  (opterm / opseason / opday / ophour  / opminute)

opterm      =   ( “OPTERM “ /  “NOPTERM” ) “=“ optermvalue  
               *( “,”  optermvalue )  /  *1( “(“ optermparam )

optermvalue  =   optermexplicitvalue  / optermperiodvalue

optermexplicitvalue  =    DQUOTE  (date / date-time) “/” 
                          ((date / date-time) / term-text ) DQUOTE

   date-time     =   date ”T” time
   date          =   date-value

   date-value    =   date-fullyear date-month date-mday
   date-fullyear =   4DIGIT
   date-month    =   2DIGIT    ; 01- 12
   date-mday     =   2DIGIT    ; O1-28, 01-29, 01-30, 01-31

   time          =   time-hour time-minute time-second [time-utc]

   time-hour     = 2DIGIT        ;00-23
   time-minute   = 2DIGIT        ;00-59
   time-second   = 2DIGIT        ;00-60 [time-fraction]
                                 ; The ”60” value is used to
                                 ; account for ”leap” seconds.
   time-fraction = 1*DIGIT
                                 ; as many digits as desired may
                                 ; may be used.   
   time-utc      = ( ”Z” ) / (( ”+” / ”-”) time-hour  
                   [ ”:” time-minute] ))
term-text        =     “THISANDFUTURE” / “THISANDPRIOR” 

optermperiodvalue    =  DQUOTE (date / date-time) “/” termperiod DQUOTE

termperiod         = ([”+”] / ”-”) ”P” (dur-year / dur month / 
                    dur-week / dur-day / dur-time )

     dur-year   = 1*DIGIT ”Y”
     dur-month  = 1*DIGIT ”M”
     dur-week   = 1*DIGIT ”W”
     dur-day    = 1*DIGIT ”D”   
     dur-time   = ”T” (dur-hour / dur-minute / dur-second)
     dur-hour   = 1*DIGIT ”H” [dur-minute]
     dur-minute = 1*DIGIT ”M” [dur-second]
     dur-second = 1*DIGIT ”S”

optermparam          =   ( opseason / opday / ophour / opminute )

opseason           =  ( “OPSEASON “ /  “NOPSEASON” ) “=“ opseasonvalue  
                      *( “,”  opseasonvalue )  /  *1( “(“ opseasonparam
)

---

From: John Stracke <[email-masked]>
Date: Wed, 18 Jul 2001 10:35:46 -0400

> <OPTERM>20020101/20021231</OPTERM>

Yeah, but that's not compatible with how iCalendar is formatted--you've 
got a property value spanning lines.  If you can avoid that, it might 
work.  You'll probably need to subset the XML so that you don't get 
anything that's not permitted in a property value (not sure what that 
might be, though).

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Reality is what refuses to go away when I stop|
[email-masked]|believing in it.                              |
\===============================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 18 Jul 2001 23:08:24 +0200

Thanks for pointing that out John.  The example should of course look
like this: (and the second line should be indented with one white-space
which my stupid Outlook refuses to let me do at this time of night.

DTOPEN;language=”XML1.0”:<OPTIMESET ID=”123”> <OPTERM> 20020101/
20021231</OPTERM></OPTIMESET>

John wrote:

---

From: John Stracke <[email-masked]>
Date: Wed, 18 Jul 2001 17:33:44 -0400

Greg FitzPatrick wrote:

> like this: [...]
> DTOPEN;language="XML1.0":<OPTIMESET ID="123"> <OPTERM> 20020101/
OK, then. Yeah, that might be reasonable--take the property value and 
pass it through an XML parser. 'Course, I might be biased, because I'm 
already using an XML parser in my app, so it doesn't seem like any 
particular burden to me. ;-)

You might consider going for a simplified subset of XML--e.g., 
forbidding the internal DTD subset, the doctype, etc. That'll make it 
easier for people who don't have any need for a full-power XML parser. 
An XML parser isn't a large hit in a desktop or server app; but I could 
see SKiCal being used in some kind of embedded system--say, to turn on 
the Open sign during opening hours.