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

On Thu, 8 Apr 2004, David Woolley wrote:
>
> For HTML and CSS, the problem is that the people who come up with the
> implementations don't have to write a complete and concise specification,

This may have been true in the past.

At the moment, the active members of the CSS working group consist almost
entirely of implementors (engineers and QA) and people who have a lot of
contact with real world authors, or are such authors themselves, and who
in addition understand both the concepts of separation of form and content
and the concepts of reducing complexity and indirection in specifications.

I like to think it shows.

But then I'm one of those members so maybe I'm biased.


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

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.


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


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


> If you take SVG, it seems to me that this is very much being driven by
> the developers.  If the W3C philosophy were driving it, I think SVG
> would take more note of integration with HTML, but instead, it happily
> uses EMBED, and the original promise of a universally available language
> for simple vector diagrams has been forgotten (you need to load
> plugins), in favour of competing with Flash.

There is nothing about SVG that prevents it from being integrated with
HTML (well, apart from stupid things like it requiring a different way to
parse the CSS, it having a different name for the event handler parameter,
etc, but those are minor issues). Mozilla has SVG builds that show this
off quite well.


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


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

</venting>

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 8 April 2004 05:29:54 UTC