[xml-dev] Debating "civil disobedience" against overly complicatedspecs

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

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!]