"Uh, what do I need this for" (was RE: XML.COM: How I Learned t oLove daBomb)

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Dave Winer [mailto:dave@userland.com]
> Sent: Friday, August 17, 2001 12:20 PM
> To: Al Snell; Michael Brennan
> Cc: xml-dev
> Subject: Re: XML.COM: How I Learned to Love daBomb

> 
> With all due respect, I think this list has missed the 
> maturation of this technology.
> 
> It's moving forward steadily.

I don't think there's anything in Edd's article that disputes this.  He's
talking about the gap between hype and reality, not the practical reality of
SOAP and RPC.  I bet we can all agree that SOAP/XML-RPC are "good things"
that are maturing steadily.

Think of Edd's example of the car that reschedules appointments/tickets if
it finds itself in a traffic jam.  Similarly visionary scenarios are at the
heart of many presentations by Big Company execs about XML, Web Services,
etc.  I also bet we can all agree that XML, SOAP, etc. *enable* the
cross-platform, real-time, information exchange that would be necessary for
the "opera loving car" to become reality, but they could only contribute a
relatively small percentage of the code needed to implement the overall
solution.

I think Edd's point goes way beyond the Web Services example:  The W3C and
other XML-related "standards" bodies were formed as industry consortia to
address specific coordination problems: what set of HTML tags should
everyone support? What subset of SGML is appropriate for the Web?  Can
something like DSSSL with XML syntax rather than Scheme syntax be useful?
What are the common features of everyone's Dynamic HTML APIs and how can
they be extended to handle XML?  The result was the "hard core" of the W3C
specs that actually work: HTML 3.2/4.0, XML 1.0, XSLT, DOM. I know that a
lot of us agree on this point, and I'll bet that SOAP 1.2 will be part of
that "hard core" before long.

Edd's more original observation is that most of the industry has learned the
wrong lesson from this:  They act like there is some "XML juju" that
magically generates success when the BigCo's come together under the W3C
umbrella: "The new model seems to be that the largest companies propose
something, and
everybody else rushes to agree by joining the relevant Working Group."  This
misses the reason for the W3C's success in its heyday:  The original
proposals that were thrashed out by W3C WG's were real-world, concrete
matters of coordination.  We're now, arguably, getting into areas where the
largest companies are proposing things primarily to help their bottom lines
rather than facilitate interoperability; Web Services are an appropriate
example, because the whole paradigm is being driven by economic needs to
generate increasing license revenue during a technological plateau AT LEAST
as much as it is driven by technical coordination requirements.

So, the message I get from Edd's article is: The W3C (et al) operated
successfully as a forum for technical coordination when things really did
move in "internet time."  The W3C may serve well as a technology incubator
for more visionary ideas (e.g. the Semantic Web) now that the rate of
commercially-driven innovation has slowed. But we have to beware that the
XML *technical* infrastructure (the W3C, the conferences, etc.) is not being
hijacked to serve the *marketing* needs of the major stakeholders...

So, now the question we must ask -- about Web Services, the Semantic Web,
all the specs piled up on top of and along side the Hard Core XML specs is
"Uh,
what do I need this for?"   I don't think Edd, or me, or anybody else is
saying "We don't!" ... we're saying that the question should be asked and
answered satisfactorily before the YAP-ping begins.