W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Chaos, Process

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Wed, 31 May 2000 14:47:25 -0400
Message-Id: <200005311845.OAA10117@hesketh.net>
To: <xml-uri@w3.org>
At 01:04 PM 5/31/00 -0400, Tim Berners-Lee wrote:
SSL>[This is a set of side issues TimBL brought up in the 
SSL>Moving on thread.  They're important, but I fear that 
SSL>they could muddy that discussion in communal violence, 
SSL>so I've separated them.]
TBL>(A good idea ...whenever the actual topic changes. 
TBL>Other list users take note.)

I changed the header again, as I plan to address only a portion of your
reply initially while I sort out the rest.  I hope you didn't mean
'communal violence' was a good idea, though I fear that further conflict
may be where this is headed long term.

[I've attempted to clean up line breaks and indicate writers as well,
hoping to make this more readable.  TBL1 refers to comments from a previous
message than the one to which I'm replying]

TBL>Yes, I suppose feel hurt when I and a team of people who
TBL>have been paid to do it work hard to bring people together 
TBL>to form plans for the future which all can agree on, and 
TBL>somehere down the road, our attempts to hold ongoing activity 
TBL>together by pointing out the ties which bind it are referred 
TBL>to as "random"!  Often, the w3C staff are in a very difficult
TBL>position when groups seem be very happy to work independently
TBL>and prodcue something which in the end didn't fit together.  
TBL>Then, the team's job is to point these things out.

From the outside of the black box, there appears to be an enormous amount
of randomness inside the black box.  The view on the inside may well be
different.  We simply have no way of knowing, and being told that documents
published as NOTEs have 'axiomatic' status makes life even more confusing.

I'd like to point out that 'random' is not necessarily bad, or even
unorderly.  Systems that aren't predictable frequently produce better
results than systems that are predictable.

You seem to disagree, but that may have something to do with your role as
Director of a research organization that appears to believe strongly, if
occasionally, in a top-down approach to building Web architecture.

TBL>When someone on an open list attacks the ties 
TBL>which bind the system together, it may be a time 
TBL>for feedback and it maybe a time for education. It 
TBL>may be a time for more complex process. But it is a 
TBL>time to respect other parts of the system.

I'm not certain why you're feel 'the ties which bind the system together'
are being attacked.  There are a lot of people with some serious questions
about W3C decisionmaking, and I don't think this discussion has done much
to address those questions. Still, I don't hear anyone, even those with
doubts, calling for or making attacks on the system.

TBL1>With authority comes responsibility.  One cannot 
TBL1>give public accountability of a form which allows a 
TBL1>random veto by those only interested in part of the 
TBL1>system, and "allergic" to other parts (as you put it). 
SSL>A good issue to address, though the way you 
SSL>phrase it displays your own biases vividly:
TBL1>One cannot give public accountability of a 
TBL1>form which allows a random veto by those only 
TBL1>interested in part of the system, and "allergic" 
TBL1>to other parts (as you put it).
SSL>If this were to reflect my own perspective, it might have read:
SSL>|One cannot give public accountability of a form which allows a
SSL>|random veto by those individuals and corporations who happen
SSL>|to be in positions of control, at the expense of communities
SSL>|that have spent considerable effort developing best practices.
TBL>Ok, I can compare those two paragraphs carefully.  Under 
TBL>the process, the individuals and corporations and other 
TBL>organziations which are involved in W3C work within a 
TBL>process so that their actions are not random.  

I don't quite understand your apparently severe irritation with the word
random.  I've seen many processes produce results that seem random, or
suffer long periods where internal contradictions can't be resolved.
Merely setting up a committee within a process doesn't exorcise these
demons - and it probably shouldn't.

From the outside, these decision-making processes frequently appear random.

TBL>For example, 
TBL>when the staff analyse the working group response to last 
TBL>call comments there is a commitment that the document
TBL>should only go though if they have been addressed appropriately.
TBL>So the result of the review cannot be random.  There is no veto.

The result of the review will be as good as the effort that went into the
initial document and the review.  'The result of the review cannot be
random' is a major overstatement.

'There is no veto'?  I thought the Director of the W3C had real power over
Recommendations, limited only by the costs of infuriating large blocs of
members but (within the process itself) absolute nonetheless.  I suspect
this leads to smaller vetoes within W3C process as well, but can't confirm

TBL>By contrast, on a public list, there is no commitment to any 
TBL>process so that people can be free to criticize for their own 
TBL>purposes. I am not criticizing people here, I am comparing 
TBL>processes. I am interested in and have spent a lot of time in both.

There is no commitment, but there is frequently community.  Communities can
and do create things of lasting value.  I'd point to SAX and SAX2 as one
example, and the work coming out of SML-DEV (see
http://www.docuverse.com/smldev/index.html) as another.

There may be more visible randomness, but what coherence exists is also

TBL>You say "in position of control".  What is control? Who has 
TBL>control? Many people on this list write code, and that controls 
TBL>what actually is.  That is control, maybe.  The appearance of 
TBL>power which the consortium has stems from the fact that people 
TBL>in it consort - they agree to work together.

Code writing provides some level of control, if you can get people to use
your code.  Some organizations do very well writing code that reflects
their needs and distributing it, others don't.

The 'position of control' that the W3C has is rather tenuous, in some ways,
but much stronger than other consortia in other ways.  The history of the
W3C's director has given it considerably more 'moral authority' than any
other vendor consortium I'm aware of, and its work affects a larger body of
people.  Instead of being merely as strong as its members' commitment, the
W3C can also trade in on the well-wishes it receives for past success.

Within the W3C, it's clear that there are various positions of control, as
there tend to be in any vaguely sophisticated design process.  The
decisions made by the holders of those positions - be they members,
editors, staff, or the Director - have an enormous impact on a much larger
body of people than the W3C officially holds themselves responsible to.

It seems likely, even probably that that 'larger body of people' will not
always share the goals and interests of the W3C itself.  Griping about
negative responses from that larger body and trying to push 'axioms' on
that body doesn't seem very productive.  I'd suggest a friendlier form of
community outreach.

TBL>They participate and commit things. Time - that they will review 
TBL>other people's specifications. Money - to provide an infrastructure 
TBL>and a full-time staff to help with the vary challenging business 
TBL>of collaboration and consensus across cultures. They also make a 
TBL>commitment that they are working toward an interoperable solution 
TBL>across the board.  The result has prodcued some specs. No one has 
TBL>to use them, but because a lot of people put a lot of time in, and 
TBL>because the way they fit together has been the matter of some 
TBL>thought, they are generally considered useful.

I participate and commit myself to public projects all of the time, without
pay.  I write and review specifications, and participate in discussions
about those specifications.  Some of those might even prove to be useful.  

All of those projects are performed in a less formal process than that of
the W3C. There may be randomness contained in some of the specifications.
On the other hand, it's much easier to figure how those specs appeared -
all discussions are  public, including vetoes.  Explaining gaps isn't that

SSL>Reconciling those two will be difficult, of course.  
SSL>Balancing top-down directed development with organically 
SSL>unmanaged bottom-up development is rarely a fun job.
TBL>Yes.  Some weblike mixture is what works in practice.  
TBL>It is getting the balance. And for each person realizing 
TBL>where they fit in.

I worry about 'Weblike mixtures' here.  I strongly hope that the 'Weblike
mixture' you have in mind refers to the early highly collaborative Web you
initially proposed, and not the mostly-read-only Web that we have today.

I'm also not sure that "each person realizing where they fit in" is
meaningful in this context.  If I was feeling cranky, I could read that as
"you're not a member, so go away."  Since I'm trying rather hard not to be
cranky, I'll just worry that you're suggesting that how people fit in is
somehow obvious, when in my (limited) experience, it's definitely not.

TBL1>I think some form of public issues list with incoming 
TBL1>issues automatically logged, and disposition including 
TBL1>hypertext links to the resolution, may be a good interface 
TBL1>between a working group and a wider public interest group.
SSL>Sounds like a good idea, one I'd like to see the W3C put in 
SSL>practice across all of its activities.  That'd help, certainly.
TBL>We have had the plan on the table for a long time.  <sigh/> 
TBL>We wanted a moderated state-tracking system for architecture 
TBL>discussions. But in fact the tools are not things you can get 
TBL>off the shelf and we don't have unlimited resources to spend 
TBL>on creating them.

Well, at least the intent is good.  I've been happy to see a number of
working groups (XLink, XML Schema) using their public lists quite actively,
a nice change from previous times when public questions went (publicly,
anyway) unanswered.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
Received on Wednesday, 31 May 2000 14:45:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:59 UTC