Altova Mailing List Archives

RE: ubiquitous XML?

From: "Simon St.Laurent" <simonstl@--------.--->
To: XML-Dev Mailing list <xml-dev@---.--->
Date: 11/21/2000 4:04:00 AM
At 02:29 AM 11/21/00 -0800, Chris Lovett wrote:
>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 we're looking through opposite ends of the telescope here.  I'm
concerned that building more and more complex features on top of XML
threatens to compromise its accessibility, while you're arguing that
complex features are necessary to avoid compromising its use on large
software projects.  Those two sets of issues could be compatible, but right
now I feel strongly that they're competing.

>I think the feds should split up this w3c juggernaut
>before it completely stifles the future of XML :-)  Sorry couldn't resist.

There's some seriousness in that irony, I'm afraid.  Some competition at
least might be a good thing.

>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.

Certainly.  But there are a lot of people with conflicting needs, and not
all of those needs are well-represented or well-regarded.  _Who_ exactly
does XML Schemas open 'unbelievable opportunities' to?  Your community
perhaps, but not necessarily mine.  What are the costs?  Yours are
different from mine.

>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.  

If you're fond of top-down development, you're fond of top-down
development.  I've never found 'the man at the top' surrounded by
'architects' to have much appeal or success, to be honest.  It doesn't
scale very well, either.

If ubiquitous XML is just a matter of Microsoft building it into their
software and selling it to users, your approach may be fine.  If ubiquitous
XML involves bringing users into the process and letting them create data
structures and pathways which meet their own needs, I'd suggest your
approach is limited at best.

>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.  

That's been brought up before, but I can't say I've seen much enthusiasm
for it.

>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.

Maybe it'll just take an order from the 'man at the top'.  I'd suggest that
it's harder than that, by far.

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


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.