[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Use cases for XML failure (was Re: #2 Re: [SML] Whether tosupport A
----- Original Message ----- From: Eric Bohlman <ebohlman@n...> To: Michael Champion <mike.champion@s...> Cc: <xml-dev@i...> 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|