xml-dev - Re: Obfuscating XML with namespaces

[Jonathan Robie <Jonathan.Robie@SoftwareAG-USA.com>]

Mike Champion wrote:

>The world can alway vote with its feet and override the votes of any
>standards committee.  If the XML family of technologies do indeed prove too
>obfuscated for the needs of industry, we can expect "YML" or "ZML" or
>whatever to come along and rectify the mistakes that we refuse to face up
>to.  We've seen Java get a lot of acceptance by addressing the "mistakes" in
>C++, and we see C# trying to address the "mistakes" in Java. We already see
>JDOM addressing the "mistakes" of the DOM, RELAX addressing the "mistakes"
>of XSD, etc. The marketplace of money and ideas, not the W3C or ISO, will
>ultimately decide which specs prevail.

The marketplace does decide which standards succeed, and the world clearly 
should ignore some standards.

On the other hand, the world should also accept some less-than-beautiful 
standards if we want interoperability. Since XML is often used as a hub 
language, interoperability is key. Suppose part of the market decides to 
accept YML, another part sticks with XML, and another part accepts ZML. Add 
seven or eight different schema languages, each purported to be the 
simplest or the best by some vendor, and a couple of programming languages, 
each of which is best. Now shake thoroughly and ask the marketplace to 
decide. The result? The marketplace decides it is confused.

So far, the marketplace seems to be accepting the core standards of XML, 
including XML, XSLT, DOM, and the non-W3C SAX. On balance, I think the W3C 
has done a pretty good job of balancing generality and complexity - though 
every single standard I work with has things I don't like, and some things 
always seem more complex than I would prefer. Namespaces are part of the 
established standards. XSLT in particular supports namespaces and relies on 
them, and the W3C has come to a definition of namespaces that people can 
live with. This process has taken a couple of years. Do we want the W3C to 
spend another couple of years rethinking these decisions? Or do we want to 
fragment the market with a set of competing standards? If we want 
simplicity and interoperability, I do not think that either of these 
approaches are helpful.

I like the idea of another language coming along and correcting the 
mistakes of XML the same way Java corrected the mistakes of C++. However, I 
think that we may need more time to see what XML is and how it is used over 
the next five or ten years before we will really have the knowledge we need 
to do it right. We are still learning how to use XML in everyday 
information processing. I think that years of using C++, Smalltalk, and 
ML-derived languages was a necessary part of the education of the people 
who wrote Java. We will need a similar education before we are ready to 
invent the next-generation XML. Also, C++ has not exactly died out, and it 
continues to be used for quite rational and practical reasons - C++ got a 
lot of things right, and is often the best language for writing high-speed 
engines.

I'm afraid that we on the standards committees find ourselves making 
imperfect decisions based on inadequate knowledge and experience, and these 
decisions affect the many people who use these standards. Another way of 
saying exactly the same thing: we are doing creative and innovative work in 
areas that are not always well-understood, and our work, though imperfect, 
is likely to be widely used.

Jonathan