Re: iCalendar as an XML DTD

[Chris Newman <Chris.Newman@xxxxxxxxxxxx>]

On Wed, 15 Apr 1998, Paul Fonte wrote:
> 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.

Multiple transport mechanisms for a data object can be a very good thing. 
But multiple representations of the same data object is counter-productive
to interoperability.  Take lossless image formats, for example.  We have
BMP, X-bitmap, PCX, PNM, GIF, PNG, TIFF, etc.  Isn't it obvious that we'd
be better off with only one or two of these rather than hundreds?

In addition, suppose the new XML-iCalendar variant starts getting
deployed?  Now we need to gateway between the two formats which is likely
to add new errors and complexities to the system.

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

Yes there are specific technical deficiences in the XML spec.  My summary
list from a quick skim of the spec follows:

* Didn't define BNF notation.
* Processing Instructions introduce interoperability problems.  There
  is also no registry for PITargets.
* "<![CDATA[" notation is cumbersome and creates new parser state and
  alternate representations.
* Version number text is broken -- likely to leave things stuck at
  "1.0" just like MIME-Version.
* Reference to UCS-2 which doesn'treally exist.
* Too many encoding variations.  &#x;  &#; &; UTF-8, UTF-16.
* Byte-order mark replicates TIFF problem.

		- Chris