xml-dev - RE: ubiquitous XML?

["Simon St.Laurent" <simonstl@simonstl.com>]

At 09:54 PM 11/16/00 -0800, Chris Lovett wrote:
>1. XML is not a passing fad.  It is here to stay, despite all the weird and
>wonderful things we are all building on top of it.  XML is simply the
>standardization of an incredibly powerful design pattern that has existed
>for eons and will continue to exist for lots and lots of reasons.  The
>standardization of this design pattern is a hugely powerful thing creating
>all kinds of new opportunities from PDA to Mainframe and everything in
>between.

I'm certainly not arguing that XML is a passing fad.  What I'm arguing is
that the current approach to XML's continuing development may in fact
stifle more possibilities than they create.  If complexity grows faster
than capability, the net benefits are only apparent to those for whom
complexity is not a cost.

XML's initial rise had something to do with its approachability, and the
tools which supported it.  While the tools are continuing to improve,
however, the overall approachability is (IMHO) declining.

>2. The true genious behind simplicity is when it does not limit the complex
>from being possible.  This is the balance we must all strive for as we
>continue to drive the evolution of XML and it's related family of
>technologies.

This is a nice vision.  However, it lacks perspective on the costs which
the complex can inflict on the simple.  While 'XML 1.0' still means more or
less what it did in February 1998, 'XML' no longer has the same meaning.
For some perspective on what 'XML' now includes, I'd suggest taking a look
at Xerces or MSXML, parsers which have grown capabilities well beyond XML 1.0.

Keeping the simple out of the way of the complex does not keep the complex
out of the way of the simple.  It's easy to say "If you don't like the
features, don't use them."  It's very difficult not to have to deal with
the features, however, if you don't have complete control over the set of
XML documents you are expected to process.  In certain limited cases, it's
easy not to use the features, for now.  In the total set of XML use cases,
however, there are many situations where different expectations require
developers to deal with the full range of possibilities.

It's also easy to say "Hide the complexity in tools."  While there are
undeniably better and better tools emerging for XML, those tools aren't
available in every situation, nor do they necessarily reflect the full set
of capabilities in the specs.  Again, this works, but only in a limited way.

On top of these problems are real integration problems created by the
continuing evolution of the XML specification family.  Namespaces in XML
introduces incompatibilities with XML 1.0 processing, and W3C XML Schemas
introduce a post-schema-validation-infoset which is only accessible to
those who use XML Schemas, not to mention some new interpretations of
Namespaces in XML.  XInclude adds some functionality to XML 1.0, but
inflicts new transition costs on developers.

There aren't obvious ways to make these things interact cleanly, but there
are some very good questions about how this layering works and doesn't
work, which might eventually lead to answers which allow the 'simpletons'
to get along with the 'complexities'.

>3. Sometimes the most valuable tool in software development is the garbage
>can.  When a given solution doesn't stand the test of time, then be honest,
>put all politics aside and start over.

Mortality in specifications may well be a good thing, but I don't see any
of that happening in the near future.


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books