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

>In my experience most of the groups who turn out specs that are IMHO much
>too complicated are groups who are (possibly unintentionally) only
>targetting professionals (e.g. XForms, SVG).

Some of these technologies needed to come about and yes I agree that there 
are a lot of specs that seem only usable if you never have to look at the 
markup yourself (XML Schema and RDF come to mind). I find that my interest 
in a spec is heavily influenced by the simplicity of the spec itself. I 
would not be surprised that many a potential reader ran screaming from a 
spec after seeing it.

>There is also a lot of focus on re-using existing W3C technologies and not
>reinventing them -- for example some groups are reluctant to use their own
>attributes for links, instead using XLink -- which leads to compromise
>solutions being propagated into other specifications in the name of unity
>and reuse.

Which is especially unfortunately when the spec stinks. One of the problems 
with these specs that I've found is that they don't take sufficient time to 
show what their technology would look like in other specs.  What does XLink 
look like in an HTML document? I've spent many hours trying to figure out 
what exactly a data document looks like with XLink attached and I have a lot 
of trouble. A spec isn't done until it gives good examples on how it's 
supposed to interact with various types of XML documents (pure data, 
document (ala HTML), schema and query/programming).

> > W3C then has to try and reduce what they have done to a simple, complete
> > and self consistent set of rules that both matches the policies for the
> > technologies and is as close as possible to matching the de facto
> > behaviour of the common products in the straighforward cases, in spite
> > of the border cases all really being handled by secret code in the
> > developed products.
>
>Not all of the cases involve secret code (Mozilla comes to mind).

I  was appauled to see how much hacking (the not so nice sense) had to 
happen to cover all the cases in Mozilla. If your system is that ugly, 
perhaps the spec needs to be rethought. Special cases are the bane of 
programmers everywhere.

> > Generally standardisation is done after the fact.
>
>In the groups I'm involved in or peripheral to, this is not really the
>case. In particular the CSS, XHTML, SVG, and XForms groups all tend to
>write specifications before (or in tandem with) implementations.

And certain specs are better than others and I think it shows.

> > CSS is funny in that it was created as part of trying to clean up HTML
> > but is being driven by marketing driven feature creep.
>
>There's actually very little marketing force behind CSS right now. And the
>CSS group is the only group to be truly looking for dual interoperable
>implementations before releasing a CR spec to PR, which is making it even
>harder for the specs to be poor.

And yet they still are. It is not enough to advance good additions to a 
language, one must also look at the core of the language and how the new 
features will interact with the older ones. Personally I think how the box 
model works in CSS to be insane. CSS has huge problems that haven't been 
addressed. Some of them can be fixed finally with the advent of HTML 2. 
(embedded sections come to mind), but a lot of the problems still remain. 
I'd also be willing to bet that most of the people using CSS don't realize 
that CSS could be immensely better. They seem content with it for the most 
part.

Understanding complex concepts in Computer Science doesn't show 
intelligence, it just shows you have a lot of time on your hands. Let's 
strive for simplicity.

> >> Perhaps it would be best if the W3C suspended activities on new specs
> >> to work on simplifying the specs they've already written.
> >
> > As I've tried to argue, the complexity is created by the commercial
> > side, not by W3C.  That complexity is hidden in the details of the
> > proprietory source code but gets revealed in the standards when you try
> > to write a complete and self consistent document.
>
>I strongly disagree. The error handling bits aren't ever really encoded in
>specs, so the complexity from them is not the complexity in the specs. The
>complexity in, for instance, XForms, comes from the entire model (it has a
>three tiers of abstraction). The complexity in SVG comes from the sheer
>size of the feature list.

Yes. The specs themselves are too complex without regards to their 
implementations. If I as an individual can come up with specs that do as 
much or more than the existing specs, write the engine for them _and_ still 
have the whole thing easier to author, than what the hell is wrong with the 
W3C?

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 Thursday, 8 April 2004 11:10:12 UTC