OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: PC Week on "Why XML is Failing" ?????

[ Lists Home | Date Index | Thread Index ]
  • From: Steve DeRose <Steven_DeRose@brown.edu>
  • To: <xml-dev@XML.ORG>
  • Date: Wed, 26 Apr 2000 15:29:40 -0400

At 1:17 PM -0400 4/26/00, Michael Champion wrote:
>Take your favorite antacid and check out
>http://www.zdnet.com/pcweek/stories/news/0,4153,2551691,00.html
>
>The essence of the article is that vertical industry B2B efforts are
>flourishing but the "pure XML" efforts such as OASIS are not:
>
>"The losers are pie-in-the-sky XML-indoctrinated organizations, such as the
>Microsoft-spearheaded BizTalk.org and OASIS. The automakers chose to bypass
>BizTalk and OASIS to develop proprietary (but published) schemata. Every big
>organization will do the same, and though some of their XML work may feed
>back up to OASIS or BizTalk, every one wants standards for their cliques
>only."
>
>I tried to draft a response but couldn't figure out where to begin, given
>the swamp of misconceptions the author seems to build upon.  Is this worth a
>response, perhaps by a prominent person in the XML community, to distinguish
>the undeniable success of XML from the possible failings of ebXML or
>BizTalk?  For that matter, I'm not at all sure the author understands what
>OASIS or Microsoft are trying to accomplish, so even their "failure" to
>solve the world's problems may not be quite so stark as the author suggests.

I agree they have some naive ideas in the article; but overall, it looks
like old news to me. I'm glad the press has now figured out what many XML
people have been saying for a long time: XML gets rid of totally pointless
incompatibility over how to punctuate your data structures when you pass
them around, but it doesn't solve the problem of disagreeing over the real
data structurest that ought to be passed. That's just what was intended.

Expecting XML to solve that would be like expecting linguistic grammar to
solve political conflicts. Without a basic (if perhaps imperfect) agreement
on grammar and vocabulary, all bets are off. But once you can actually talk
to each other, you can *start* actually working on whatever the real
differences are. Common language is necessary, but not sufficient.

Now in natural language it's best if negotiators speak some common
language, but we have workarounds: highly skilled translators can
substitute; and no culture makes their language intentionally opaque, or
holds it under non-disclosure (well, maybe the Auca). Even so, translators
simply do not exist for many combinations of the world's 5000 or so
languages (300 or so if you only count ones with armies). So, for example,
the UN uses only a few "main" languages; even a mere 300 languages would
lead to 900 potential translations -- and there are many more B2B,
e-commerce, and other corporate content things than a mere 300 or 5000.

Such linguistic workarounds are infeasible in computing, so we need a
common language even more: for which XML is working quite well. XML saves
writing a parser for every app; it saves worrying about what to do with
CR/LF, or what the 3rd bit over in the 'charformat' mask byte is; it saves
worrying whether *this* RDB's comma-delimited export form escapes "," with
backslash or by quoting -- all that mindless, useless junk that has nothing
to do with your information, but causes a continuous drip of wasted
programmer-years.

But XML does *not* solve the problem of semantic heterogeneity (a topic
discussed in reams of database articles). XML never meant to; nor does it
seem a feasible task. From my perspective, one of the best things I
expected from XML was simply that it would make the *real* semantic
problems visible: it is no longer so easy to miss the substantive
differences behind a veil of syntactic obfuscation. By making the problems
visible, at least we can deal with them consciously and directly.

Well, now we're there. XML lets us all see, in plain text and schemas, just
what the differences between two competing systems were to begin with; and
companies that want to interchange, convert, or compromise can do so
explicitly and clearly. The process also helps directly: as companies and
whole industries move to XML, they get a perfect chance to review and
perhaps fix schema problems that have been there a long time.

Companies that are arch-rivals may avoid compromise, or even introduce
different schemas just to create incompatibility; I don't think there's
anything we can do about that. But there's a Darwinian process going on
here, and being gratuitously different can lead to extinction. Working
together is more efficient than working alone, and economies of scale favor
standards in the long run.

At the same time, perhaps we will find that some of the mavericks have seen
something everybody else missed, and we'll all be tweaking our schemas to
add it.

Let the weeds grow along with the wheat; if we try to root them out now,
we'll doubtless kill some of the good stuff too. They'll be weeded out in
time.

Just saw Tim's posting while writing this one. I second his points too.

Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
Chief Scientist, Scholarly Technology Group, and
   Adjunct Associate Professor, Brown University
North American Editor, the Text Encoding Initiative



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS