xml-dev - OASIS/SAX - looking around

["Simon St.Laurent" <simonstl@simonstl.com>]

At 01:09 PM 2/11/00 -0800, Jon Bosak wrote:
>There are no closed doors in the OASIS process.  All OASIS TC
>mailing lists are open to public view.  

That's good to hear - back when the XML repository discussions were
starting, I got a rather different response to my request to participate.
(That was before individual memberships were available.)

However, looking at that committee's site today, I can see:
http://www.oasis-open.org/html/rrpublic.htm

I see lots of information on this page, but no link to the actual
discussions that produce the work.

There's still a members-only page:
http://www.oasis-open.org/committees/regrep/index.html

Is that where the work gets done?

>The $250 membership dues
>entitle you to *write* to the lists; reading is free to everyone,
>and there are no confidentiality rules to prevent open discussion
>of what goes on in OASIS TCs in lists such as xml-dev.  (On the
>contrary, open discussion of the workings of OASIS TCs in public
>discussion lists is an implicit part of the process.)  The dues
>are simply what it costs to maintain the lists and keep the
>organization running.

I'm glad to hear that there is no confidentiality, but I have to wonder why
$250 for mailing list participation makes sense, especially for the
development of small standards like SAX that have already found a niche.

>Despite its success so far, the process you've got now for SAX is
>not democratic.  It puts all decision-making authority in the
>hands of a single person.  The fact that the person in question
>happens to be above reproach does not change the fact that this is
>a benevolent dictatorship.  I don't buy the benevolent dictator
>model of standards development no matter how highly I regard the
>dictator of the moment.

David Megginson is dictator (hail, David!) until either he or the community
decides otherwise. Since SAX is public domain, there's nothing except an
interest in interoperability and general approval of the dictatorship's
performance keeping SAX development from fragmenting.

To me, that's a lot better than a vendor-funded forum for managing
corporate interests through committees.  A low-budget approach to standards
development can avoid the death-by-committee specs certain organizations
seem intent on creating.

>The question of whether matters of policy should be decided by
>groups or by individuals is, of course, one on which people have
>different opinions.  There are tradeoffs either way.  One of the
>things you get from a formal democratic process is that
>institutions can adopt the products of the process.  In the
>current model of SAX development, no really large institution
>(government agency or large corporation) can adopt SAX normatively
>because there is no guarantee of where SAX will be 10 or 20 or 30
>years from now and no guarantee that anyone building
>mission-critical systems around it will have any input to the
>process that evolves it.  No one who has contributed to the effort
>thus far has any control over what happens to SAX in the future,
>either.

I think you've somehow decided that a committee of paying members is a
democracy while a well-coordinated mailing list project is a dictatorship.
Simultaneously, you've placed the interests of large agencies and
corporations above the needs for smaller organizations for small flexible
and low-cost standards that work today.  

If ISO wants to standardize SAX after the development process is done, I
don't think I'll object.  I will, however, object to taking SAX into a more
formal environment while there are still immediate needs shared by a common
community that should be sorted out by the widest possible share of that
community.

I have no control over the future of SAX, and I really don't mind.  This
isn't corporate IP that the legal department needs to grasp in its talons -
it's an important grass-roots effort that addresses the immediate need to
parse XML.

>In the absence of a democratic process, SAX will be defined by
>companies like Sun and IBM that build it into their products.  The
>first time that IBM makes a change to their version of SAX, the
>opinions of this group cease to be relevant.  The notion that you
>are somehow in control of what happens to SAX under the current
>arrangement is completely illusory.  What I'm suggesting is that
>the group that developed SAX take actual control of it in a way
>that prevents it from being stolen out from under you.

Maybe it's just that I'm an independent worker, but this argument sounds
like the legal department talking, not a developer community.  I'm afraid
my experience with the folks who make such arguments has not been
encouraging.  

I'm not seeking any kind of actual control over SAX, nor do I expect any
such thing.  My few minor contributions have been made very much in the
spirit of a gift economy, with no expectation that they would form any kind
of binding contract.

>| If David Megginson wants to put SAX in the hands of OASIS, he is
>| of course welcome to, as the keeper of the spec, but the rest of
>| us groundling can still have fun with what's public domain, I
>| guess.
>
>It's a common misconception that "public domain" makes things
>free.  In fact, a paradox of intellectual property law is that
>"public domain" means almost exactly the opposite in practice, for
>reasons that I'm not legally qualified to explain but are well
>known in the open source development community.  This is why all
>open source development projects scrupulously avoid the concept of
>"public domain" and use a different model based on various clever
>kinds of licensing.  OASIS IPR works the same way as IETF IPR and
>really does protect collaborative intellectual property
>development in the way that most people think "public domain" does
>but actually doesn't.

I'm aware that public domain has its limitations, but licensing
specifications is a lot harder in legal practice than licensing code.  I'm
pleased that David chose a wide open, though certainly risky path.  

I hope that SAX remains tightly connected to the community of developers
who have created it, and that the ever-growing need for interoperability,
that often-taken-for-granted aspect of all XML development, is enough to
keep the legal departments and vendor consortia out of the picture.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com