[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] re: Do We Need James Clark to get Good Recs?
Thomas B. Passin writes: > Sometimes it seems to me that most of the XML-related Recs/Specs > that xml-dev'ers approve of are those that James Clark had a major > influence on. Sax is an exception, I suppose, but that had David > M. playing a unifying role, so maybe it is in a similar category. SAX is not as much of an exception as you might think, since it was heavily influenced by James's SGML parsers ab initio, then by James's constant advice, criticism, and encouragement during the initial development. > I would like to ask a few questions about this. > > 1) Is this perception widely shared on the list? > 2) If so, is it specifically James, or is it the mode of development? > 3) Are there any examples of good/elegant/approved (by xml-dev'ers) recs > that were developed in a different way? > 4) If there is a mode of development that tends to lead to especially > good/elegant/etc recs, can we foster that mode? Or does it take specific > individuals with very special knowledge and personal qualities? I cannot claim to have done any proper scientific survey, but I've noticed a few common characteristics among specs: 1. Simplicity succeeds. It is unlikely that a spec will be successful unless specialists in the field complain that it is far too simple for real-world use ("I've been working with markup since 1988, and I know that in industrial-strength projects we need to ..."). Pre-W3C HTML is the classic example, but remember that networking types once looked down their noses at TCP/IP as well ("It's fine for academic research, but ..."). Sometimes the specialists get their revenge in v.2 by joining the process and smothering the spec to death with new features. 2. Process is poison. It looks good on paper, but in practice formal process doesn't work at all, at least not for initial spec development. XML 1.0 was developed mostly under the radar at the W3C; after that, it became very hard for the W3C to do any useful XML work (DOM and XSLT succeeded only because they were already well underway). Process is a good thing in a perverse way after a v.1 release, because it slows down work and postpones the usually-catastrophic v.2 release. 3. Code first, then specify. Anticipatory specs for problems people haven't tried to solve yet are just wild, random shots in the dark; at best, they waste everyone's time, and at worst, they cause confusion and hostility. Most existing XML-related specs should not have been written yet: we don't need a spec to cover X until many, many people have been trying to implement X for a while and have discovered where a common spec might be beneficial. A new field of development shouldn't *start* with a spec; it should *end* with one. 4. Almost every new spec fails anyway. Specs are more like frog or fish eggs than they are like infant mammals -- we lay hundreds or thousands in the hope that at least one or two will make it to adulthood. There is no way to guarantee success, even by taking the previous criteria into account. All the best, David -- David Megginson, david@m..., http://www.megginson.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
|