OASIS/SAX - looking around
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format