RE: iCalendar as an XML DTD

[Dan Hickman <dhickman@xxxxxxxxxxxxxxxxxx>]

Chris,

We DEFINITELY DO NOT want to have multiple grammars for any standard.  You 
would be unnecessarily creating two standards that developers must 
implement.

This standard was designed to promote interoperability.  We would be doing 
the worst thing possible to hinder interoperability if we allowed multiple 
grammars.  If two grammars were specified, then developers would be forced 
to implement parsers/generators for both grammars to ensure that their 
application would interoperate with any other application.  This is 
unnecessarily forcing duplicate work and would be the death of this 
standard because it makes no sense.

I, for one, couldn't tell you the first thing about why XML wouldn't be 
good for iCalendar.  Actually, when I first looked at XML, I thought it 
would be a good idea to use something like it since there are parsers 
already available for it.  I think the main argument against XML for 
iCalendar is that the iCalendar standard is already finished and is built 
on a proven grammar that is fairly compatible with the first version of 
iCalendar (vCalendar).  It is too late to change it.  Please, lets get this 
standard out so we can actually start using it!!

Thanks,
Dan Hickman
Rockin' Software
dhickman@rockinsoftware.com
http://www.rockinsoftware.com

> -----Original Message-----
> From: Paul Fonte [mailto:pfonte@ontime.com]
> Sent: Wednesday, April 15, 1998 2:02 PM
> To: Chris Newman
> Cc: IETF calsch WG; Mark Baker
> Subject: Re: iCalendar as an XML DTD
>
>
> so far, the responses to proposing XML as an alternative
> delivery format
> to the CALSCH format for the data appear to be less than friendly.
> this piques my curiosity.
>
> to me, the hard work of this group has been very well presented in the
> data format contained in the current work products.
> i don't understand the resistance to a parallel _delivery_ format.
>
> in order for CALSCH to become accepted as a commodity product (i hope
> that's one of our goals), it would seem that encouraging as many
> delivery mechanisms of standard data would be a logical conclusion.
>
> is there something i am missing here?
> does my logical separation of data from delivery formats not
> make sense?
> doesn't this discussion at least point out that an important
> design goal
> may have been partially accomplished (separation of content from
> delivery).
>
> i am most concerned by the vagueness of statements made in
> criticism of
> XML and i am less than swayed, can anyone offer specific, concrete
> technical reasons not to pursue the translation?
> are there specific deficiencies of the XML spec that haven't been made
> public?
>
> justwonderin
>
> paul fonte
>
>
> Chris Newman wrote:
> >
> > On Thu, 2 Apr 1998, Harald Alvestrand wrote:
> > > Doesn't mean it's a good idea.
> > > XML is a complex tool, and has yet to prove its value in
> a real-life
> > > situation, no matter how much the press says about it;
> "in vogue" and
> > > "useful" are not necessarily overlapping categories.
> > >
> > > ...
> > >
> > > It does not seem to me that CALSCH needs to join the
> queue of willing
> > > volunteers for trying out XML for various purposes.
> >
> > I concur with Harald on this point.
> >
> > In addition to being unproven in the field, XML is about an order of
> > magnitude more complex than the format CALSCH uses. I'm
> also not happy
> > with the idea of basing open-standard work like CALSCH on
> closed-standard
> > work like XML.  XML repeated a number of design errors I've
> seen made in
> > various IETF work over the years and it's annoying to be
> stuck with such
> > design errors again.
> >
> >                 - Chris