Re: iCalendar as an XML DTD

[Antoine Leca <Antoine.Leca@xxxxxxxxxx>]

Mark Baker wrote:
> 
> At 03:00 PM 15/4/98 -0500, Dan Hickman wrote:
> >We DEFINITELY DO NOT want to have multiple grammars for any standard.  You
> >would be unnecessarily creating two standards that developers must
> >implement.
> 
> We could and should make the XML based grammar optional
<snip>

There is something I do not understand here.

If XML is optional, how should a CUA (as it is specified now) should behave
if it receives a object in this new format?
If it is required to understand it, XML is really not optional...
If not (i.e. the CUA can react with a 3.X answer), this is of no value (at
least in the interoperability realm), because there is little chance (unless
something escaped me) that XML-iCal successed to be used; in fact, I see it as
just added burden.

OTOH, if we think with a CUA understanding XML in mind, how should it react
when receiving a "vCalendar-like" objects?
If this one is optional too (in some context outside current iTIP, of course),
this leads to a situation where:
- good quality implementations (of CalSch softwares) should be able to support
both formats (I think this explains the reaction of some implementators here);
- some poor-man implementations will support only one, thus leading users to
be unhappy of that (a BAD thing for us);
- also, interoperability gateways between the two formats will be needed, thus
added software and complexity (and bugs); more users unhappy...
- and big companies (like mine) will just wait to see which one of the two
formats will succeed, thus this will increase greatly the time-to-market of our
work (another BAD thing for us... and for me too!).

The real big point of XML, in the eyes of a company which does not have yet an
market-ready product but plans to have one, is to give it some delays...
I figured that almost all big companies in the CalSch's field was involved
in our work.  Was I wrong?


> >[...] iCalendar standard is already finished [...].
> >It is too late to change it.  Please, lets get this
> >standard out so we can actually start using it!!
> 
> Agreed, but that shouldn't so much (IMHO) be considered an "argument
> against XML"

I disagree.

> , as it should be considered a challenge to find room for
> coexistance.

I think we are speaking of interoperability.  Two formats are not
a good thing in this realm.

 
Phil Wolff wrote:
> 
> Please consider the relative populations of developers who know about and
> are developing to the iCalendar spec vs. those now developing to XML.

In the context of implementors of CalSch softwares, this is very clear, indeed.

Put it another way, there is far more people that knows the syntax of Java than
there are people that knows the formats of Excel files.  However, if you
are developing a new spreadsheet (or related) software, the latter is much
more useful than the former.


> imho, XML is going to be the dominant new protocol for 1999

Could be right, indeed.

> and specs like iCalendar can ride that wave of acceptance by speaking the language.

This is the knot, IMHO.  Should we delayed our work by some months to "ride the wave"?


>     By this fall, Navigator, Mozilla, and IE will have XML parsers and, according
> to all the specs I've seen, will not have iCal parsers.

They have not announced CalSch viewers either, so this can explain that...
I cannot see why a XML version of iCal will change this (having the format is not
the only thing to produce a CalSch tool, even it is limited to viewing; if you are
unsure, read the specs about RRULE ;-)).


>     Wouldn't it be advantageous to have one representation for both calendaring
> tools and browsers? If so, then XML is your only choice.

See above for the implications (IMO).


Antoine