[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Debating "civil disobedience" against overly complicatedspecs
I've been reading Elliote Rusty Harold's forthcoming "Processing XML with Java." chapters that he is very kindly posting on his website. In the most recent chapter on XML APIs http://www.ibiblio.org/xml/books/xmljava/chapters/ch05.html he says "I found some major design flaws in ElectricXML" ... "My major technical concern about ElectricXML is that its reputation for ease of use has been achieved primarily by catering to developers' preconceptions and prejudices about XML. In other words, the API is designed around what developers think the XML specification says rather than what it actually does say." [specific examples involving namespaces snipped] "I agree that the XML's namespace syntax is needlessly complicated and confusing. Nonetheless, an XML API cannot fix the problem by pretending XML is less complicated than it really is. ElectricXML may feel easier at first than more XML-compatible APIs like SAX, DOM, and JDOM; but it's bound to cause more pain in the long run. " I think there's an issue here that goes way beyond ElectricXML and namespaces: Are acts of "civil disobedience" against "needlessly complicated and confusing" specs a Good Thing because they point us in the right direction or a Bad Thing because they cause chaos? I'm of two minds on this (partly because I wear two hats -- a member of the W3C DOM working group, and someone who personally believes that the XML specifications need to be re-factored over time to maximize their utility in the Real World). The mind under one hat thinks that ElectricXML is just plain wrong -- applications built with something like the ElectricXML API will not interoperate properly with applications built on the DOM when exchanging documents that use the full power of the XML namespaces specification (and probably other XML features that ElectricXML doesn't support). It IS NOT the job of an API to fix the allegedly un-necessary complications in the XML specifications; users are free to employ whatever subset of XML features best suit their needs, but tool developers have a duty to "first, do no harm" ... and opening up unsuspecting users to interoperability problems certainly causes harm. The mind under the other hat thinks that the purists are trying to hold back the tide with sandbags; in the long run, what developers THINK the XML specification says will create "best practices", de-facto standards, and tools that maintain "bug for bug compatibility" with those that support what people think XML is. If the standards-keepers want to avoid chaos, they need to make refactoring a higher priority; ElectricXML and other acts of "civil disobedience" might be the grain of sand that irritates the W3C oyster enough to form a pearl. I can't quite put my finger on the right slogan from the '60's that expresses this thought, but maybe we CAN fix the problem by pretending it isn't there! Thoughts? [other than suggesting I get my multiple personality disorder treated!]
|
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
|