Re: complexity (was: Re: XHTML and RDF)

> > 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.

I believe that's a characterization of it. However we've yet to prove that 
rubber-stamping X's ideas are a bad idea for the rest of the community. My 
question is why on earth is company Y even there. It doesn't care because it 
won't implement or use it? Does this sound like a good idea to anybody?

Also company Z can go *bleep* for all I care. It is not the job of the W3C 
to keep businesses in business. It's job is purely to create the best 
specifications and create the documentation to make them implimentable.

1) The author of a specification should be chosen for his or her ability to 
write a spec that solves all the problems presented _and_ the ability to 
listen to other people when they present new problems.
2) Other persons on a working group should leave their businesses at the 
door.

Your other option is to request complete or near complete specifications 
from the general public and pick the best one and work on it with that 
author.

> > 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.

Well I've got lots of XSLT files that I find very simple actually, but I'll 
leave room for the fact that
1) I may be doing things with them that aren't that complex
2) personal taste may be affecting judgement.

Also identity transform without modification is
<xsl:copy-of select="$node" />

Not too complex, eh?

Orion Adrian

_________________________________________________________________
Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 
months! 
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/

Received on Wednesday, 14 April 2004 11:06:32 UTC