xml-dev - SML and History

[Tim Bray <tbray@textuality.com>]

At 05:48 AM 11/11/99 -0800, Don Park wrote:
>Everyone,
>
>I have been thinking that there are applications out there that
>can benefit from using XML yet donot need all of its features.

There is some history there.  Shortly after the release of XML, some folks, 
including some very important folks in W3C and its members, who had been big 
supporters of XML, actually got around to reading the spec, and discovered to 
their horror that they had, instead of DPML (Don Park Markup Language), 
an XML which included entities, DTDs, PIs, and assorted other baggage.

As a result of that, the W3C created a Working Group called the "XML Syntax
Working Group" (now expired), co-chaired by me and Joel Nava, with a few 
deliverables, including some sort of simplified XML and also a "Canonical 
XML" format for use in conformance testing and digital signatures.  Last 
things first: Canonical XML still lives, has public Working Drafts, and 
quite likely some day be a W3C Recommendation.  Co-editors Bray/Clark/Tauber.

Simplified XML failed to happen because the WG totally failed to achieve
consensus on what it ought to be.  My memory is foggy but I seem to recall
that everyone agreed that references to external entities should be 
suppressed, but I can't bring to the front of my mind any one other thing 
that everyone agreed on.

Further complicating the picture was the lack of objective evidence that
a simplified-XML subset would actually be significantly cheaper in terms
of memory footprint or processing speed or implementation time.

Further complicating the picture was strenuous resistence by some, including
me, to any weakening of XML's internationalization capabilities.  
Restricting it to one encoding (probably UTF-8) would have had serious
cost to XML's acceptance in one part of the world or the other.  Furthermore,
since most real-world data is in EBCDIC or JIS or ISO-Latin, the net result
would have been moving the character conversion logic from the parser to
another piece of software with no net saving.

Further complicating picture was serious concern by some, again including
me, about "splitting XML".  Given the existence of a simplified XML, many
vendors would gleefully leap on board, support only that, announce to the
world that they supported XML, and throw any incoming document on the floor 
that happened to include lots of things that XML 1.0 said was legal.  
Speaking only for myself, this was the blood-in-the-water issue.

At the end of the day, I agree with Don Park that too much stuff made it
into XML 1.0 (although in the last months of the development of the spec,
we were kept busy full-time resisting the addition of more stuff).  However, 
looking back over the past couple of years, it seems that it came out 
just-barely-small-enough to hit the sweet spot.  Nobody is more conscious 
than me of the unnecessary extras in XML 1.0, but these acknowledged flaws 
seem not to be fatal nor even, in the big picture, all that serious.

For example, I'm in the late stages of building a big application with
XML plumbing that would get just fine with DPML (Don Park Markup Language).
Who cares?  I create the XML with a few printf() statements (for the
cognoscenti: ap_rprintf()), and pick up the nearest XML parser to read
it with.  The cost of having features I'm not using seems very moderate, 
and the benefit of merely having to specify "the interface is XML 1.0," 
without any fine print, seems quite high.

There is some valid concern with the growing height of the stack of 
other related recommendations that are being heaped on the back of XML 1.0.
Speaking only for myself, I surely don't have the mental bandwidth to be on 
top of XPath and XSLT and XSchema and XLink and DOM and the Infoset and so 
on all at once; I can't imagine that anyone except maybe James Clark does.
It's important that these things be built, insofar as possible, so you can 
pick and choose and just use the one or two you want without getting yourself
into complex dependencies.  So far, I think the specs have done a reasonably
good job of that.  Where they haven't, it should be treated as a bug.

 -Tim

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)