Lists Home |
Date Index |
- From: Tim Bray <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Fri, 12 Nov 1999 10:23:42 -0800
At 05:48 AM 11/11/99 -0800, Don Park wrote:
>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.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)