Cart
|
[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
 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@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
|
|||||||||
