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

>>Some things just aren't best served by a committee. Specs I believe are 
>>one of them.
>
>So as someone said to you before in the thread, you are not talking about a 
>standard creation but about a product creation with a good specification 
>document. The mission of W3C is to bring together all players in an area to 
>make them work together to create a stable version of a technology. It's 
>all about sharing the work. Producing something in your corner has nothing 
>to do with standards... and it's already done by multiple vendors :)
>
>So you have to keep in mind that.

Let me see if I can be more specific. The difference between standards and 
proprietary formats is whether or not their open. A specification can be 
either. I'm not against creating open specifications, but I feel the 
end-product is better served with only one or two people behind the vision. 
There are a lot of really great formats out there that are open that had one 
original vision behind them.

One of them is HTML. Remember that Berners-Lee didn't have a committee to 
create all the his specifications. Just him. C# is another project that 
wasn't developed by comittee and now it's an open specification.

>>>What is a specification?
>>
>>A specification is a document that describes a process or technology that 
>>is sufficiently precise enough that people can use the document to 
>>implement the process or technology in such a way that the desired output 
>>always flows from a given set of inputs.
>
>Almost agreed. You are forgetting a part, the most important. It has to be 
>interoperable. In the sense of two different persons who don't know each 
>other will be able to create a product that will be able to use the same 
>technology in an interoperable way.

That's covered by "that the desired output always flows from a given set of 
inputs."
If this is true, then it's always interoperable because any implementation 
will produce the same output given the same input.

>	And it's what standards are about. When I turn a light bulb in its socket, 
>the brand for the light bulb and the one for the socket might be different, 
>but the specs which describe the thread requirements.

I never disagreed with you on this point. Standards, internal and external, 
are important.

>>The trick is to have a single author's vision with people commenting on it 
>>and the primary author actively seeking suggestions on how to improve the 
>>specification. But always one author or a pair of well coordinated 
>>authors.
>
>Yes but this doesn't work either. Vision is fine for one product of one 
>person or one company. Not for something done in a competitive market where 
>you have to invite people to discuss and agree on the technology. Which 
>visions do you take, the one of Microsoft, Sun, Apple, IBM, or Adrian Inc.
>
>If you talk about Editors, it's mostly the case, often the documents have 
>one or two editors.

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.

You're going to have to be more specific about what an editor does in this 
context. Perhaps that's not clear enough.

>>>How do you preserve minimum interoperability?
>>
>>A person is capable of making an internally consistent concept with enough 
>>work, but given too many authors you generally end up with something that 
>>isn't consistent, but rather a hodgepodge of ideas.
>
>As I said at the start, you are not talking about a consortium, standard 
>organization, or any kind of collective organization btw.

I am. The difference is the openness and discussion of the spec and what 
pressures there are on the authors themselves.

>>>How do you try to reach maximum interoperability?
>>
>>Many simple ideas are very extensible without additional constructs.
>
>As long, you define the extension mechanism, if you don't,  you can run 
>into big interop problems.

I would still have to disagree with that statement. Extension mechanisms 
aren't required if all contingencies for a specific problem have been 
calculated. And no, they're not infinate. The problem pretty much comes down 
to looking at how you can abstract a scenerio to fit it into all the right 
virtual categories. Let's take a example mathematically at what can happen.

Some construct has X fundamental properties that completely describe it's 
behavior. Now we can create 6 properties to take care of this, or we can 
create Y properties based on what combinations seem most likely (float in 
CSS is an example). Unfortunately the number of possible combinations of 
properties is around X!. That's a lot of combinations to have to deal with, 
especially with a lot of base properties. More time has to be taken to look 
at what the best set of properties is. This definately hasn't been done.

On another point. Breaking backwards compatability is often a good idea. 
Cleaning up a design is often as important as extending it. XHTML 1.1 and 
HTML 4.01 are good specs in that regard.
RDF, OWL, XML Schema are also specs that need to cull back and rethink.

XLST, my favorite spec from the W3C is currently in danger of becoming too 
complex. EXST was a wonderful solution to many of the problems that XSLT 
had, but instead we have a much bigger mess with XSLT 2.0.

Orion Adrian

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE 
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/

Received on Wednesday, 14 April 2004 00:23:02 UTC