Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Realistic proposals to the W3C?
 A good list of questions -- thanks. > Mike.Champion@S... wrote: > PROPOSALS, RECOMMENDATIONS, AND STANDARDS? > > What do you folks WANT a "W3C Recommendation" to signify? A stable technology that meets the (publicly-reviewed) requirements of the WG. > How much > implementation experience from OUTSIDE a working group should be > necessary to enshrine something as a Recommendation? As a general rule, any implementation, whether inside or outside the WG, should turn up technical problems, so my worries are less about inside/outside that about any implementations. However, I think at least some (two?) implementations from outside the WG are necessary to ensure that any internal implementations aren't based on folklore known to the WG but not the general public. > Should the W3C > encourage Recommendations to be modular components that can be > assembled into anything from minimal subsets to monolithic > monstrosities, or should the current "one size fits all" objective be > maintained? Case by case. I think if you can show good use cases for a minimal subset, then those should be allowable. But there is a real judgement call here in that you don't want so many options that implementations can't play together due to fragmentation. > Should Recommendations be treated as "standards," should > there be a something like a "Strong Recommendation" that has survived > the test of time and the market, should the W3C refer well-established > Recommendations to the ISO, or what? In practice, Recommendations are often treated as standards. I think the idea that something can't move from CR to Rec without implementations is a good one. > OPENNESS > > Given that there's no way the W3C is going to make the detailed votes > on specific proposals available to the public (sorry, it ain't gonna > happen, so don't bother flaming me), what could it do to maximize the > benefits of "sunshine" without drying up the information flow? I can't speak for others here, but I sometimes feel like contributing to the public mailing lists is like walking past somebody in the hallway, saying, "Hi", and having them just keep walking. After a while, you begin to wonder if they know you exist. As Matthew Gertner pointed out, there is a real PR issue here. Even if the WG addresses all points on the public mailing list, the people who submit comments aren't likely to feel like their comments are worthwhile without an actual reply -- just seeing that your change made it into the next draft isn't enough, as you have no idea if you've had any effect or the change came from someone else. Although it's not always the case, I'd often be satisfied with a list of quick, point-by-point answers: "Good point. We'll take it up." "We've done it -- it'll be in the next draft." "Sorry, we've considered that and voted against it -- here's why..." Ideally, I'd like to be involved in a technical discussion of the points I raise, but if that isn't going to happen, I'd at least like some recognition that I'm not wasting my time. > Make > Interest Group mailing lists open to qualified people who agree to > respect certain guidelines (such as not publicly revealing who > advocates what)? That would make me very happy. I'm less worried about total openness than about being able to follow and, at least occasionally, be part of the process. As Matthew said, I also haven't heard any good reasons that the technical points can't be discussed with people outside the W3C. > Eliminate Interest Groups and encouraging all > technical discussion to occur on the public mailing lists and all > member-confidential stuff to remain on the WG mailing lists? If this wouldn't dry up contributions, then yes. If, on the other hand, it isn't going to happend due to member companies viewing it as too much cannon fodder for sensational journalism, then the above solution is fine with me. After all, I think what a lot of people are asking for here is to be a meaningful part of the solution. > Farm out > the public "brainstorming" of specs to OASIS TC's and produce SAX-like > "sense of the community" proposals, and only setup Working Groups when > the time comes for the heavy hitters to go into the smoke-filled rooms > to sort out who can implement what when? Farming out brainstorming is fine, but no WG is ever going to get all the "heavy hitters" on board. Opening up technical discussions with some form of non-disclosure as a condition of membership would definitely be in the W3C's best interests. > CLARITY OF SPECS > > What should the W3C as an organization do to encourage clearer specs? > Mandate a page limit? Demand a relatively non-technical but > "normative" Tutorial/Background paper to accompany all specs (at least > at the Recommendation level)? Insist on an open source reference > implementation? Mandate some other formal language description? As a general rule, I don't think you can write many rules about how to write good specs, so I think that most of what can be done here is in: 1) Having the W3C state that part of any WG's mission is education of the public about that WG's topic. Given the W3C's attempts to stay ahead of the technology curve, rather than standardizing existing technology, this strikes me as a fundamental part of their mission. 2) Tutorial/Background papers are a good way to do this, as are less formal writing in the specs, annotated specs, etc. I think it it's reasonable to let each WG work this out on their own, based on the writing styles of the spec editors. What is important is that the WG doesn't think it's job is done if their work is only understandable to them and a handful of well-educated outsiders, no matter how well it is written, precise, or complete it is. -- Ronald Bourret Programming, Writing, and Training XML, Databases, and Schemas http://www.rpbourret.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
|
|||||||||
