- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 14 Apr 2004 10:24:17 +0000 (UTC)
- To: Orion Adrian <oadrian@hotmail.com>
- Cc: www-qa@w3.org
On Wed, 14 Apr 2004, Orion Adrian wrote: > > Yes you pick the best vision. Multiple visions don't merge. You can get > an author to include a solution for a test case. But it should always be > the author's call. I believe in a combination of natural selection and > refinement. Some specs are going to die, and the standards body has to > realize that when certain specs don't meet the needs of the audience who > asked for them in the first place. I agree, but unfortunately the other people on the committee (any committee) don't. Take a working group, with companies X, Y, and Z. Company X's representative is the spec author. He thinks a particular feature should be in the draft in a particular way. The representative of company Z, however, disagrees, since doing it that way would put them out of business. There are technical arguments for both sides, and each group thinks it is the side with the clearly stronger arguments. Company Y doesn't care either way since they won't be implementing this nor using it, and are there merely to keep an eye on things since this working group is working on other features that do affect the company. What do you do? I've been both X, Y and Z in the past. I have no good answer. The answer usually used by W3C -- majority consensus -- means that effectively company Y gets to decide this. Since they have no strong opinion either way, that basically means it is a coin toss, leading to your typical design-by-committee specification. But obviously giving X the authority to chose his own option means that it is not a working _group_, but just a rubber-stamping of X's ideas. > You're going to have to be more specific about what an editor does in > this context. Perhaps that's not clear enough. Editors try to keep the spec internally-consistent while addressing the needs of all members of the working group. > XLST, my favorite spec from the W3C is currently in danger of becoming > too complex. LOL. "Currently in danger"? Even the identity transform in XSLT is ridiculously complicated. I have yet to see a single XSLT file that doesn't stand as an homage to the complexity of the XSLT specification. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 April 2004 06:24:29 UTC