xml-dev - Re: Use cases for XML failure (was Re: #2 Re: [SML] Whether tosupport A

[Eric Bohlman <ebohlman@netcom.com>]

On Sat, 27 Nov 1999, Michael Champion wrote:
> My own use case for the failures of XML is XML-DEV!  We spend a majority  of
> our bandwidth discussing the most obscure and least useful bits of the spec
> (e.g., Does Production 14 forbid the string "]]>" in all CDATA elements, or
> just CDATA marked sections?).

Warning!  Selection bias alert!

The most difficult and problematic aspects of a system are always going to
be the ones that generate the most discussion and questions; people don't
spend much time on mailing lists talking about the easy parts that
everyone already understands.  The boundary cases are always going to get
the most "coverage."  Just like in the Real World where rare events get
more news coverage than commonplace ones.  The murderer who gets off on a
technicality gets far more coverage than the murderer who's sentenced in a
quick trial, so just looking at the news gives you an impression of a
justice system that's seriously broken.

> My experience with the DOM WG *and* my recent day jobs  is similar -- the
> least useful parts of XML cause the most work for people supporting it.
> Both CDATA sections and external parsed entities caused *massive* amounts of
> work and contention for us in devising the DOM API.

I'm inclined to consider that a unique case.  CDATA sections and external
parsed entities (and for that matter, comments) have to be treated
specially by the DOM in order to accommodate a narrow class of
applications, namely editors and editor-like programs, that need to be
able to reconstitute the purely lexical structure of a document after
modifications.  The vast majority of applications using XML have no need
to know whether a particular string of characters appeared in an external
entity or a CDATA section.  An editor does.  Someone writing a non-editor
application doesn't need to master the methods for querying lexical
structure.  Their presence may make the DOM complex to implement, but not
to use.

But it's almost always the case that the design of development tools for a
system is much harder than the design of application for that system.
The complexity added to the development of the DOM specification, or even
a DOM implementation for a particular platform, is a one-time thing; it
doesn't get duplicated every time someone *uses* the DOM API.

As an example, a programming language that has an LL(1) grammar is going
to be much easier to write a compiler for than a language whose grammar
isn't even context-free, but that does *not* imply that it will be easier
for a programmer to write code in the first language.  If you're going to
say that the second language is "difficult," you need to specify *whom*
it's difficult for.  If the answer turns out to be, as it usually is,
something other than "everyone," you need to make some value judgments,
and the one usually made is that difficulty in doing rarely-done things
(like writing a compiler for the language) is worth it if the result is
less difficulty in doing frequently-done things (like writing programs in
the language).  It's very often the case that external simplicity is the
result of internal complexity.  Mathematical elegance rarely translates
into ease of use.  A minimalist set of primitives *may* be easier to
*learn* (especially if you're talking about learning as memorization
rather than learning as comprehension) than something richer, but it may
also be harder to *use* (the set of Turing-machine primitives can be
completely learned in an hour, but they're not easy to write programs
with).



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)