xml-dev - SAX, OASIS, &c.

[Jon Bosak <bosak@boethius.eng.sun.com>]

I see from xmlhack that I've become embroiled in a debate taking
place in a list that I don't s*bscribe to.  Oops.

I hope that everyone will simply allow me to start over here.

To begin with, there are a few things that people should be aware
of.

1. Regarding public access to the work of OASIS technical
   committees, the OASIS archives are at

   http://www.xml.org/archives/

   The interface leaves a lot to be desired, but all the
   non-administrative work groups seem to be open to public view.
   I am NOT RESPONSIBLE for the functioning of these mail lists,
   so I'm the wrong person to complain to when they suffer
   technical difficulties.

   Note that the publicly visible archives include not only
   messages posted in the small number of existing OASIS technical
   committees (docbook, tables, workprocess, xmlconf, xmlorg) but
   also in the working groups of the ebXML effort, which is a
   joint initiative of OASIS and the United Nations body for Trade
   Facilitation and Electronic Business (UN/CEFACT).

   The OASIS administrative lists (e.g., IPR) are properly not
   visible to non-members, and when the current crop of site
   maintenance issues abates, I will suggest to the maintainers
   that the admin lists be moved onto a separate index page so
   that the TC lists don't appear to be randomly accessible.

2. Please bear in mind that I am not a s*bscriber to xml-dev; I
   cannot begin to deal with the volume of mail it receives.  I do
   s*bscribe to the digest, but I hardly ever have time to read
   it.  (And in fact I haven't seen a copy of the digest lately.
   Hmm.)  I would end even the digest subscription except that I
   do occasionally need to post an announcement to the list.  So
   in general I'm not aware of discussions as they are happening
   here.

   Because this arrangement makes my meaningful participation on
   the xml-dev list virtually impossible, I have tried to make it
   a policy not to respond to postings that I happen to see even
   when I have strong opinions on them.  I fell off the wagon this
   time, for which I apologize.

3. While the evolution of XML core technologies is in able hands,
   there seem to me to be equally important problems related to
   the implementation of XML industrial standards that are not
   receiving adequate attention.  I have recently withdrawn from
   W3C participation in order to devote my energies to helping
   solve these problems.  Thus, I am no longer speaking ex
   cathedra with regard to W3C.  In fact, I am no longer directly
   aware of issues under discussion within W3C at all.

   I should also point out that I am not speaking for Sun either,
   but only for myself.

Trusting that that's all now clear, I'd like to address some
points that came up in response to my posting of 2000.02.11.

My comments about SAX came from an attempt to grapple with what
appear to me to be long-term problems, not just with SAX but with
the evolution of XML industry standards generally.  I didn't mean
to imply that any changes should be made to the management of the
phase of the SAX design effort currently underway; I am far too
much of an industrial pragmatist to suggest anything that would
disrupt a successful effort before it hit some natural
stopping-place.  But I am trying to make people aware of the
consequences of continuing this way over the long run.  I'm trying
to point out that the often stormy climate in which you maintain
something like an industry API is different from that halcyon
weather you enjoy during the first phases of its development.

Some questions have arisen over my comments about democracy.  My
definition of democracy is taken from the Oxford English
Dictionary:

   1. Government by the people; that form of government in which
      the sovereign power resides in the people as a whole, and is
      exercised either directly by them (as in the small republics
      of antiquity) or by officers elected by them.

"Exercised directly" means today exactly what it meant "in the
small republics of antiquity": it means voting.  "Elected" means
voting, too.  But some people define democracy as in the next
sentence from the same dictionary:

      In mod. use often more vaguely denoting a social state in
      which all have equal rights, without hereditary or arbitrary
      differences of rank or privilege.

I mean democracy in the technical sense of the first part of the
definition, not in the loose sense of the second.  Properly
speaking, the process by which SAX is being designed is not
democratic, because its only way to resolve differences of opinion
is through the personal decision of an unelected individual.  The
fact that the individual in question happens to be doing a
near-perfect job seems to make people oblivious to the problem of
how this is all supposed to work over the long run.

I am lucky indeed that circumstances have provided David Megginson
as my example; it's so silly to call him a dictator that everyone
can understand that what I'm pointing to is the potential
implications of the current process, not David himself.  In that
process, what gets done is done by David -- with due regard for
everyone's comments and suggestions, to be sure, but in the final
analysis, it's his call.  Since David's judgement is very sound
and he is very fair and knowledgeable, everyone seems to agree
that this process is working out terrifically well at the moment.
But good or bad, it's not democracy, and it won't work as SAX and
other XML standards become the foundation of our commercial
infrastructure.

It's clear, I hope, that I have no objection to the collaborative
artistic process that can inform the first and even sometimes the
second version of a technical specification.  What I'm saying is
that it is possible to operate this way only in the absence of
concrete economic interests in proposed features of the
specification.  The artistic climate in which this group has been
operating won't last when subjected to the stresses of big
competitive investments in the outcomes of certain decisions.

I can testify that you do not want to be using an unstructured
process like the one that's been working so far in this list when
it reaches the point where big chunks of people's code get written
in slightly different ways according to slightly different models
of the next release or variant interpretations of the current one,
and you have to use the list to decide whose early implementation
decisions will end up instantiated in the spec and whose ten
thousand person-hours of effort will end up in the trash can.
Without a democratic process for the orderly resolution of
competing interests, this becomes (to use a phrase Len Bullard
taught me) nothing but a knife fight.  And pretty soon it attracts
the participation of well-funded people who *like* knife fights.
This is what happens when large sums of money are involved.  I'm
sorry, but that's how it is.

I believe that David is far too sane to stay in his current role
with SAX for the rest of his life.  At some point he's going to
put the responsibility for sorting out future knife fights
somewhere else.  Whether that responsibility ends up with us, or
with a vendor-run consortium, or with the leading implementor
appears to be up to us to decide.  If we want it to end up with
us, then we have to put in place genuine, heavy-duty,
industrial-strength decision processes that can resolve real
differences between real competitors and are guaranteed to stay
open to the participation of all interested parties even when
working under full load.  It doesn't have to be done right this
minute, but it has to be done at some point if we want to remain
relevant to the direction of this technology over the long run
rather than turning over responsibility to the vendors.

The world won't end if we don't accomplish this and if future
versions of SAX and other XML standards come to be defined by
vendor consortia or in proprietary back rooms.  But we certainly
won't be left with any warrant to complain about this outcome if
we fail to provide a legal, democratic alternative.

Jon

==========================================
Jon Bosak, XML Architect, Sun Microsystems
Chair, OASIS Process Advisory Committee
==========================================

***************************************************************************
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/threads.html
***************************************************************************