examples where fixed spec targets are useful (was Re: Please explain the role of the W3C in the continuing development of HTML)

[trimmed ccs]

On 15 February 2011 12:05, Ian Hickson <ian@hixie.ch> wrote:

>> I for one can't see how that model alone can fulfil the demands of
>> organisations which rely on fixed specifications to decide policy (and
>> developers to build against).
>
> That's a different topic, but since I'm here: I hear often about people
> wanting "stability" and needing "fixed" specs to refer to, but nobody ever
> seems to notice that RECs aren't stable nor fixed, and nobody ever seems
> to mind that when people refer to RECs they immediately ignore what those
> RECs say if they have bugs, as if the specs had in fact been updated.
> (Indeed sometimes, as with XML, the specs even are updated, in place,
> despite the claims that stability is needed.) Could you elaborate (maybe
> with a somewhat trimmed cc list) on what exactly it is that these
> organisations demand, and maybe more importantly, why they think that the
> W3C model serves their needs?

I can't put the viewpoint of any orgs without doing a pile of
research, but I can describe two situations in the last few weeks
where I personally found named/versioned HTML specs useful:

Setting up a CMS for a site which will feature music releases, I
wanted something in which I'd be able to use RDFa to annotate the
product descriptions - the fact that Drupal 7 supports XHTML+RDFa out
of the box made this a no-brainer. Even if I hadn't wanted the RDFa,
I'd still have checked the supported doctypes to help confirm 'modern'
markup support and cross-browser compatibility.

(This latter part is essentially the same role specs often play in
other engineering scenarios. If I was making computer hardware and
wanted it to interconnect, I'd be better off building to a particular
fixed standard (USB 2.0, 3.0...) rather than trying to test my
hardware against all the different USB devices out there.)

I've been building a little Java app that will need a lot of
documentation nearby. Sun had the foresight to use HTML as the
document format for their JavaHelp system, making it pretty much ideal
for my requirements. But I found that a lot of my existing docs would
be unsuitable as-is, in fact the JavaHelp indexer failed entirely on
some. But it didn't take me long to discover the cause: JavaHelp was
built for HTML 3.2. Although the markup version wasn't my only
consideration, finding the Oracle branch of JavaHelp, OHJ - which
supports HTML 4 - essentially cured this problem.

If I hadn't got the spec versions as reference markers, I'd have had
to go through trial and error on all the features, and probably still
risked uncertainty with future docs.

Cheers,
Danny.

-- 
http://danny.ayers.name

Received on Tuesday, 15 February 2011 22:46:42 UTC