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

["Michael Champion" <Mike.Champion@softwareag-usa.com>]

----- Original Message -----
From: Eric Bohlman <ebohlman@netcom.com>
To: Michael Champion <mike.champion@softwareag-usa.com>
Cc: <xml-dev@ic.ac.uk>
Sent: Saturday, November 27, 1999 2:51 PM
Subject: Re: Use cases for XML failure (was Re: #2 Re: [SML] Whether
tosupport Attribute or not?)

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

Good point as to why we spend our time arguing about the corner cases in
XML-DEV.  Nevertheless, the Real World can't afford the luxury of a legal
system that arbitrarily chops off the corner cases.  But we're not talking
about designing a legal system here, we're talking about designing a
dirt-simple markup language for *simple* messages and documents.  We *can*
arbitrarily decide the corner cases, because people who don't like SML's
handling of them can simply use XML or SGML.  That might cost them
something, but it won't put them in jail.

> 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).

Another very interesting counter-example.  Clearly we need layers of
abstraction on top of whatever the underpinnings are, SML or XML or
whatever. Clearly most people are going to use the higher-level
abstractions. I'd argue that those higher-level abstractions are -- in
general -- going to be easier to build on top of a minimal, elegant
foundation.

Otherwise, the kludges perpetuate themselves.  For example, consider XML
Production #14 that we've talked about today ... it was put in to ensure
compatibility between XML and SGML parsers ... and now some people are
saying that the SML proposal "crosses the Rubicon" because it's planning to
remove this, i.e., making it possible for legal SML to be rejected by an XML
parser.

I know that I signed up for the DOM activity partly out of an innocent
belief that reasonable abstractions presented to Web programmers could help
promote XML.  Over and over again, the very things that Don is removing from
XML to make SML got in the way of defining those abstractions.

Maybe my DOM horror stories are not relevant, as Eric suggests.  I think
they are -- it's an honest effort by knowlegeable people to apply a simple
face to the complexities of XML.  Others will wrestle with that problem,
even if they don't want to!  And FAR more people are going to find that is
is strange and stupid (to belabor my favorite example today) that you can't
put the string "]]>" in an XML element without escaping it than will find it
useful to be able to parse XML with an SGML tool.





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)