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.

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

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
http://www.simonstl.com - XML essays and books