xml-dev - RE: ubiquitous XML?

[Chris Lovett <clovett@microsoft.com>]

The funny thing is that all the problems you list are all the classic
problems we run into on large software projects where we break down the
problem into components or "modules".  With the added extensibility of
componentization comes the cost of complexity and poor integration across
project boundaries.  I think the feds should split up this w3c juggernaut
before it completely stifles the future of XML :-)  Sorry couldn't resist.

I don't see how you could possibly think the standardization efforts are
stifling opportunity.  The presence of these standards is opening up
unbelievable opportunities that we would barely dared to dream about just a
few years ago.

How do you overcome poor integration and overwhelming complexity?  You get
the man at the top to pound out the "simplicity, simplicity, simplicity"
drum beat.  You appoint architects that have a track record of achieving
simple powerful designs to influence the design across the board.  Maybe
each working group should also be required to submit their stuff to a "user
study" that measures the complexity, approachability of their work and
rejects it if it fails the test.  

Some things may just need to get a trim around the edges, for example, soon
it may be time to trim DTD's out all together.  Some things that prove to be
way off track may need to get axed or completely redesigned.  A deprecation
strategy is essential otherwise the burden of carrying all the dead wood
will bury us.  Dead wood really does stifle innovation.


Chris.

> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Friday, November 17, 2000 3:12 PM
> To: XML-Dev Mailing list
> Subject: RE: ubiquitous XML?
> 
> 
> 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
>