- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 15 Feb 2011 23:46:05 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-archive <www-archive@w3.org>
[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