Re: iCalendar as an XML DTD

[Mark Baker <distobj@xxxxxxx>]

At 11:00 AM 17/4/98 +0200, Antoine Leca wrote:
>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?

It can reject it if it doesn't recognize it.

>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.

Initially, yes, that's true.  But as mentioned, I believe CUA and CS
vendors will support the XML version for a multitude of reasons.  If they
don't, then so be it; the market will have chosen.

>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);

I'm not expecting even a medium-term coexistance between the two formats.
I would expect the XML format would become the dominant one.

>- 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...

>From my point of view, I don't see it that way.  I'm already going to have
an XML parser on the client, so there's hardly any extra complexity.  YMMV
of course if you're just focusing on pure-CUA software, not generic
document browsing of which calendar access is just one aspect.

>- 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!).

It's just another syntax for the same information.  It's not like the
information itself is changing, so it's not really a big deal.  Worst case,
implement something that can treat both formats identically; a filter pair
to do bidirectional conversion, a DOM or SAX driver for the existing
format, etc..

>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?

I'm not sure what you're asking here.

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

Right.  It's a transitional plan.  One format is the eventual goal.

MB
--
Mark Baker.  Chief Technology Officer, Beduin Communications Inc.
Ottawa, Ontario, CANADA                     http://www.beduin.com