W3C home > Mailing lists > Public > www-archive@w3.org > November 2006

Re: Charters for review

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 21 Nov 2006 23:53:07 +0000 (UTC)
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Chris Lilley <chris@w3.org>, Hypertext CG <w3c-html-cg@w3.org>, timbl@w3.org, dino@w3.org, steve@w3.org, www-archive@w3.org
Message-ID: <Pine.LNX.4.62.0611212343580.14596@dhalsim.dreamhost.com>

On Tue, 21 Nov 2006, L. David Baron wrote:
> >
> >     First Working Draft in October 2007.
> >     [...]
> >     Reissued Last Call Working Draft in 2020.
> >     Proposed Recommendation in 2022.
> 
> For example, the WHATWG <canvas> specification has been implemented by 
> three browsers

Not all of it, because pieces have been added based on implementation 
feedback over time. Also, it has a large number of outstanding issues, and 
needs some work to make the prose more precise. I wouldn't say it is 
particularly stable. The features it describes probably are, but the text 
itself is no more stable than the table processing model section that I 
wrote over the last week.


> Ideally, different parts of a large document could be marked as being at 
> different stages in the process.  Perhaps that's a lot to ask (both of 
> W3C management and of document reviewers), but I think it would help 
> align specifications with reality.

That could work, but would require pretty substantial changes to the W3C 
Process Document.


> Perhaps this could be approximated by maintaining a master document, 
> using a tool to remove the parts that aren't at a given maturity level, 
> and publishing the incremental updates to each maturity level as HTML 
> 5.00, 5.01, etc.?

This is a lot harder than you might think. For example, the parser depends 
on the IDL for the HTMLDocument object, which depends on contenteditable, 
which depends on selection, and so forth. Trying to mechanicially extract 
the "complete" parts would be a lot of work, and might even involve 
things like splitting IDLs apart. I wouldn't recommend it.


> I'd rather define a comprehensive test suite as one that:
> 
>  * has tests adequate to verify that each normative sentence in the
>    specification applying to browser conformance (as opposed to
>    document or authoring tool conformance) is correctly implemented
>    in at least the basic cases, and
> 
>  * has tests adequate to verify correct interaction of features
>    whose interaction is interesting or potentially problematic.
> 
> The rule about sentences should cause the complexity of the test suite 
> to scale with the complexity of the spec, and also provides further 
> incentive to keep the specification simple.

I don't really mind how it is phrased, so long as the decision of whether 
the test suite is complete or not is an objective one, and not a 
subjective one. Words like "adequate" or "comprehensive" or "interesting" 
are subjective and their meaning is very likely to change over time.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 21 November 2006 23:53:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:00 GMT