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


Help: OASIS Mailing Lists Help | MarkMail Help



   Will XML change the character of W3C? Was: Re: sunshine and standardsde

[ Lists Home | Date Index | Thread Index ]
  • From: Amy Lewis <amyzing@talsever.com>
  • To: xml-dev@lists.xml.org
  • Date: Sat, 14 Oct 2000 21:34:22 -0400

I've been following this debate with interest, and with, perhaps, more
sympathy towards Simon's point of view than most of the posters in this
thread appear to have; I'm uncomfortable with the closed nature of
W3C's specification-development efforts.  I tend to compare this with
the IETF process, which (like W3C) produces non "standard" standards,
distributes those standards for free, and uses the rule of
implementation as the major benchmark for acceptance (more so than W3C,
in fact).  It's possible, I think, to say that one of the distinctions
is that everyone on an IETF committee is an "invited expert," meaning
that large companies don't get representation for a fee, and the
inevitable barrier to entry is there one of skill, not of choice of
employer (this is not to say that anyone sponsored by a member org is
necessarily less skilled, mind).

On Sat, Oct 14, 2000 at 06:56:47PM -0400, Simon St.Laurent wrote:
>Mike Champion wrote:
>>In this scheme of things, the problem is that people see the W3C 
>>as both crafting technologies out of thin air and having their 
>>Recommendations treated as if they were standards.
>Exactly.  The results of the 'research lab' are posted as more-or-less
>final, and only in rare cases (like ISO HTML) is there another process
>creating STANDARD standards on top of them.

But this is the IETF model, and you really ought to blame them for this
"confusion" of development with standardization.  Only I don't think
that the confusion is avoidable: when you're dealing with the network
(either with the protocols, or as with W3C, with data transfer and
application presentation standards), you *can't* travel the ISO route;
that produced the lovely and famous OSI model, but no practical code,
in the long term.  That is, without the test of implementation, which
requires releasing standards *before* they're ready, so that problems
can be found, and especially so that *cruft* can be removed, there's no
joy in generating network standards.  The process has to be
interactive: development feeds standardization feeds development, and
having two organizations in charge, rather than one, is likely to be
more productive of bureaucracy than of sound, implementable

>>These activities MUST be separate, as much as it would be 
>>convenient for us all to move directly from revolutionary 
>>technology advances to universally accepted standards without 
>>a period of chaotic natural selection in the middle.
>It's convenient to move directly, and it does seem to give the W3C a strong
>selling point for getting people to buy memberships.  Unfortunately, those
>activities ARE NOT separate in reality, whatever the documents may say on
>the surface.

I think that this is true, and I think that, in the realm of W3C
standards, this tends to mean that the vendors who can afford
representation are going to 1) have advance notice of the shape of
future standards, 2) be able to shape those standards (within limits)
to meet their needs, but also 3) these vendors are going to also use
their muscle in the market to make the standards real.  That's what I
think the tradeoff is.  W3C allows itself to be "bought", and in so
doing has gained the power of those vendors.

But ...

[snip, and a reversal of order from the original quoted material]

>>Nevertheless, as long as the W3C serves as the "treaty 
>>organization" within which pragmatic compromises that 
>>result in consensual Recommendations are made, I don't 
>>believe that more "sunshine" would help.
>Then perhaps it's time for the W3C to leave the treaty organization
>business, and focus on technical innovation. 

Here, Simon, I don't think you are correct.  From my outsider's
perspective (I've followed the web since UNC got its first connections,
back around '90-'91, but I haven't been involved in the creation of
things), the W3C has two outstanding successes to its credit, and one
major fiasco, all three of which I think are likely to be in the minds
of policy makers at W3C.

The fiasco is HTML 3.0.  W3C didn't really start as a standards
organization, after all, or as a vendor consortium; it started as a
sort of forum of folks wanting to popularize the web as a means of
intercommunication.  At the height of the browser wars, W3C went
bumbling off toward HTML 3.0, a standards-development project that paid
no visible attention to the "earth-shattering" advances then taking
place in browsers, which were released with rather astonishing
frequency (and that whole muddle is in large part responsible for the
chaotic and fragmented nature of the modern web, I think).  W3C was
roundly ignored, leading to ...

HTML 3.2, the first spectacular success, and the event that really
turned W3C from being an organization for the advocacy of HTML and HTTP
to being a vendor consortium.  W3C became a treaty-making organization,
and one of the sacrifices was the "purity" of the original HTML spec. 
But by including the (sometimes horribly crufty) features that the
major vendors demanded, W3C was also able to get them to agree to
implement the other (horribly crufty) features that the competition
insisted on, and by getting that agreement, also able to label certain
things as "not standards-compliant HTML," and have that mean something.

So I don't think that the powers-that-be within the policy-making
structure of the W3C are ever likely to unlearn treaty-making.  The
burn from HTML 3.0, and the resolution in 3.2, probably goes deep and
will last long.

But the other outstanding success of the W3C is of a completely
different character.  That's XML.  The spec is brilliant (it's *short*! 
You can read and understand it!  And the content provides truly
enormous power).  Initially positioned as a resolution of the problems
and shortcomings of HTML (so I first learned of it, at least), it has
turned out to have deep-reaching implications that have not yet been

In fact, the XML standard, for the first time (insofar as my knowledge
of W3C goes) created a situation in which the vendors were scrambling
to catch up, giving W3C time to produce additional thoughtful things
like XSLT/XPath and SVG.

What I'm trying to get at, I guess, is that with the introduction of
XML, W3C began to change character, from the treaty-making represented
by HTML 3.2 (and CSS, ineffective as that attempt was), to something
more similar to the innovative role played by the IETF.  In the days of
treaty-making, the relatively long-term process that the IETF has in
place was a barrier; the W3C *had* to keep up with the vendors. 
However, I think that XML may have changed that: it's so rich and
complex a ground that the vendors are going to be playing keep up with
that alone for some time yet, especially for the data-centric

So perhaps web time has slowed, and it might now be possible for W3C to
open its process as fully as IETF (I'm a rabid admirer of the IETF, as
you can tell).  I'm not sure, though, that that will happen, given that
the history of the W3C teaches the lesson that the 800-pound gorillas
*gotta* be listened to.

>>and perhaps more willing to defer to the ISO on the really messy 
>>business of casting Recommendations into concrete Standards.
>There have been a number of questions about ISO's fitness for this task -
>I'd love to see some of the more ISO-aware folks here talk about how such
>relations work and what might be done to improve them.

Boo, hiss!  I'm sure that there are some ISO folks here who will take
me soundly to task, but that's *not* a path I want to see any
organization travel.  The problem with those folks is that they have
truly evil fee scales.  You can't buy their stuff for the cost of
publication, or the cost of publication and shipping, or the cost of
publication and shipping and warehousing and a fine meal at the three
star restaurant of your choice.  Some of the prices for specs are
astonishingly extortionate, and effectively mean that interested lone
developers have no chance of looking at them.  They're clearly priced
to be taken as a business expense.  So even when a standard is nice and
stable, I don't want to see it under the aegis of ISO or its member
institutions, because the only way I could afford to read the silly
things would be to convince my manager that I really, really have to
have it (and then wait for delivery, unless they've managed to finally
get the bugs out of the electronic delivery system (and gotten their
standards into a format other than MS Word)).  I've had to get
standards from ISO and ANSI for several different projects, and both
pain and expense were astonishing and unpleasant.  In contrast, I pay
the cost of connection to download a zip containing all of the RFCs
(something I wish that W3C would do, btw, since the specs are in a
bewildering variety of formats, and half the time when I download them
I end up with all sorts of interestingly broken links).  So can any
developer who wants to implement a non-standard standard issued as a
Request for Comments by IETF (and if you're willing to cope with the
pain of searching out and downloading the things, the same goes for
W3C).  As a quick example, getting the first three (framework,
foundation, cli) parts of the SQL standard (there are two more parts,
for stored procedures and language bindings), from my price check a
moment ago, would run $500.  I don't get a discount for having
purchased a previous version, of course.  Standards are the only thing
I can think of that have pricing models less attractive than software.

I don't think, regardless of government legislation requiring
compliance, that turning over perfectly usable standards to
organizations that aren't capable of producing them is the solution
(that's a jab ... I had to write decodes for ISO SP and TP at one
point, and had to pay for the standards (bloody company I worked for
was too cheap) ... and the vendor dropped the whole stack from their
suite of tools anyway, on grounds of lack of interest, because not even
the government uses that stuff).

So, rah rah the IETF and the open model of the IETF, and may W3C move
in that direction, as XML's publication may let them do.

Amelia A. Lewis         alicorn@mindspring.com           amyzing@talsever.com
I don't know that I ever wanted greatness, on its own.  It seems rather like
wanting to be an engineer, rather than wanting to design something--or
wanting to be a writer, rather than wanting to write.  It should be a
by-product, not a thing in itself.  Otherwise, it's just an ego trip.
                -- Merlin, son of Corwin, Prince of Chaos (Roger Zelazny)


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

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