Must XML be SGML compatible? (Was: An incompatible CData idea)
ak117 at freenet.carleton.ca
Tue Oct 28 20:30:53 GMT 1997
Jarle Stabell writes:
> I don't see many benefits of being SGML (syntax) compatible (except for
> some obscure "political reasons"), nearly the only thing I (not being a
> SGML guru!) can think of are:
> * The ability of using non-XML-aware SGML tools on XML documents.
> How long will this benefit be of any substantial value?
That's hard to say. There is an enormous number of SGML document
systems now in place, and (as we know now with the Y2K pseudo-crisis)
companies are _very_ reluctant to change their software once they've
installed a new system, especially if the system is the result of an
expensive and difficult project.
Of course, SGML itself also suffers from this problem -- any revisions
to the standard will cause serious problems across the installed base
and confusion among users ("But I though SGML was standardised...").
> If XML becomes very popular, I guess all SGML vendors will upgrade their
> tools in a very short time, as explicitly supporting XML will be a nice
> thing to have on the feature list (and is easy to implement if you already
> have the SGML machinery).
Yes, but companies and other large organisations do not upgrade their
software the way that individual users do. If you have set up a $2
million document-production system, and somewhere buried in the middle
of it you have an old version of Omnimark or Balise chugging away,
you're hardly going to upgrade that tiny chunk and risking bringing
the whole system down (especially since the contractors who set it up
are probably long gone). Why do you think most of the world's data is
still managed by DB II and not by Oracle or Sybase (etc.)?
> One of the benefits may be that parsing XML documents will run noticeably
> faster with a XML-specfic parser than a general SGML parser.
I don't know enough about automata theory to know if this statement is
true (or even verifiable) -- it seems to me, though, that the number
of productions in the grammar shouldn't affect parsing speed, and I do
know that SGML is designed explicitly to avoid backtracking by
requiring no more than one look-ahead token (to everyone's
More generally, there are two other advantages to XML-compatibility
that you omitted:
1) Credibility: by tying itself to a well-established international
standard (ISO 8879), XML can win over conservative users in
important areas like financial services and EDI.
2) Implementation: the XML standard will live and die partly based on
the enthusiasm of early implementors; piggy-backing on SGML gives
it a good, experienced implementor-base right from the start.
I understand your frustration with the SGML compatibility, but without
it, the market would have to give XML 5 or 10 years to prove itself
safe and stable; with it, XML can start right now (or as soon as the
!@#$% spec is finalised).
On that last point, it's time to stop fiddling, kids -- let's finalise
the basic XML syntax now, so we can concentrate on higher-level
standards like DTDs, architectures, APIs, etc.
All the best,
David Megginson ak117 at freenet.carleton.ca
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev