W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: Changes to the Status of this Document section to address recent feedback

From: Doug Schepers <schepers@w3.org>
Date: Sun, 13 Jan 2008 08:27:47 -0500
Message-ID: <478A11D3.9080800@w3.org>
To: Ian Hickson <ian@hixie.ch>
Cc: jason@jasonjgw.net, public-html@w3.org

Hi, All-

Hixie, thanks for the remedial steps.  I personally agree that this is 
appropriate enough for a First Public Working Draft, and look forward to 

I'll note that it's only because of the extraordinary impact and legacy 
of HTML that this is an issue; in practice, many specifications are 
implemented concurrently with drafting the spec, and as long as the 
vendors and authors are willing to be flexible, it's not as much of an 
issue (and can even be informative and lead to better specs).

Jason, I made a suggestion last month for a progressive implementation 
report [1], to  reduce the risk of implementations jumping too quickly 
on unstable features before they are adequately discussed within this 
WG.  I'd be interested in your feedback.

[1] http://lists.w3.org/Archives/Public/public-html/2007Dec/0245.html

-Doug Schepers (not speaking for W3C)
W3C Staff Contact, SVG, CDF, and WebAPI

Ian Hickson wrote (on 1/13/08 2:36 AM):
> Hi Jason,
> On the recent questionnaire, you wrote:
>> The Status section of the current editors' draft does not clarify
>> sufficiently that publication as a W3C Working Draft does not imply
>> endorsement by the W3C, its members, or participants in the working
>> group of the contents of the specification.
> I have added a paragraph to try to address these needs. Please let me know 
> if the new text isn't clear enough.
>> It should also be clarified that any aspect of the specification may be 
>> revised, so that potential implementors do not (drawing on the current 
>> wording regarding maturity) make assumptions concerning which aspects of 
>> the document are mature and hence open to implementation, in a way that 
>> could later be taken as grounds for not changing those parts of the 
>> specification which have been subject to early implementation.
> The third paragraph currently prominently says:
> | Implementors should be aware that this specification is not stable. 
> | *Implementors who are not taking part in the discussions are likely to 
> | find the specification changing out from under them in incompatible 
> | ways.*
> (The emphasis is present in the spec too.) I can't really see any good way 
> to make this clearer. Is this text really not enough?
> Note that in practice, as far as I know, all the vendors who are likely to 
> be affected by changes in the spec are active in this working group, and 
> are also aware of the more fine-grained stability markers in the WHATWG 
> version of the spec, so I don't think it's really a big concern.
> (While there are certainly other vendors who aren't in the working group, 
> they are less likely to be affected by the changes to the spec going 
> forward, since they are more likely to be implementing features that are 
> already deployed in the "big four" browsers, and thus are unlikely to 
> stray in to the features where we could make changes.)
>> With suitable disclaimers in place in the Status section, I would
>> support publication, as this is a formal heartbeat requirement, not
>> an endorsement of the specification by the working group, and it
>> would be beneficial for a working draft to be circulated publicly
>> for wider review and comment.
> I hop the changes above allows you to reconsider your vote.
> Thanks,

Received on Sunday, 13 January 2008 13:27:53 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:25 UTC