Re: iCalendar as an XML DTD

[Antoine Leca <Antoine.Leca@xxxxxxxxxx>]

Hi,

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

You are clear enough, but I remain to be convinced (of either side).

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

I do not know XML.  My current knowledge is that it does not embeed the
methods to actually use informations; am I wrong?

So I fail to understand the real difference with iCal+iTIP+iMIP (except
of course the fact that is much easier to embed in a browser, thus make
it travelling on http:, and the hype -- an important thing, not to be forgot).


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

If this is true, then the CUA have to be upgraded to parse both, right?
(so they are not available *now*; moreover some won't, in order to be
cheaper, thus leading to the poor-man implementations referred above;
and we always choose cheaper products if they afford the necessary
functionnalities; if by any chance a major company like Microsoft
or Sun or Lotus or Corel or Netscape choose this way, this will decay
into a raging battle to impone its views: nothing good in my view).

And there will be 2 formats for the same informations, right?
Currently, at least Microsoft and Lotus have nearly-ready products
that will support the vCal format. So this one have a huge chance to
be widespreaded.  Unless they withdraw their plans *now* (and make
this publicly)...

This is the kind of things that, when I present a software as candidate
to wide use, makes it refused without any doubt.
A company like mine cannot afford the luxury to invest in deploying
CalSch interoperable softwares around all the workstations (on our
Intranet) if there is a risk, as little it can be, that the underlying
format have any chance to be dropped in medium term: this is simply
to costly.  So we will stay away to promote using iCalendar at large
scale, until the problem decays (of course, if this comes for free
in other products, we shall use it: but this will be almost certainly
poor-man implementations).


> >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 am giving the devil's argument: the real interest now for changing iCal
spec from using vCal format to XML seems to me to give a hand to late
candidates to this promising market.
Unless there is a compelling (read functionnal, not hype) advantage of XML
over the vCal form, which is not something evident to me now: but I repeat,
I do not know XML.

> >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 am testing my argument: is there some company not currently involved in
the iCal/vCal specs which is preparing a CalSch software?

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

A buy-nothing point to add is that we (almost) already have it...



Cordialement,

Antoine