[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Debating "civil disobedience" against overly complicatedspecs

  • From: "Champion, Mike" <Mike.Champion@S...>
  • To: xml-dev@l...
  • Date: Sun, 23 Sep 2001 20:14:56 -0400

electricxml

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.