- From: Glenn Adams <glenn@skynav.com>
- Date: Sat, 18 Aug 2012 11:36:36 +0800
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-html@w3.org
- Message-ID: <CACQ=j+d47rgL+wGxsfeEkWuRqphLc3EXWut9i=_AcxDsB9N7Yw@mail.gmail.com>
On Fri, Aug 17, 2012 at 12:30 AM, Benjamin Hawkes-Lewis < bhawkeslewis@googlemail.com> wrote: > On Thu, Aug 16, 2012 at 4:35 PM, Glenn Adams <glenn@skynav.com> wrote: > > There are a number of formal standards organizations waiting on HTML5 to > > reach REC (in any form whatsoever) so that they may publish standards > > documents that formally reference HTML5. > > Formally reference it for what purpose? > Does it matter? Basically, formally reference it in the normative reference sections of their standards/specifications. > > > From this perspective the goal is to get to REC ASAP regardless of the > > quality level (spec correctness, testing, etc), though of course the > hope is > > that quality level will be as high as possible given other constraints. > But > > nobody expects a spec this size to be bug free. > > What will happen when downstream specifications you mention reference > an HTML spec that is incorrect: i.e. does not describe how web content > is best consumed? Mightn't this lead to a downstream spec requiring > documents to be produced that are not compatible with how browsers > have to operate to consume the web corpus? > What normally happens. Standards and specs are revised over time. No mystery there. > > What are the other constraints here? If correctness isn't what the > downstream specifications need, what is the content they do need? A > feature list? A markup vocabulary? IDL? > Who said correctness isn't needed? Quality/correctness is a continuum. Obviously anyone who is writing a down stream spec desires HTML5 and any other referenced specs to be as correct as possible. But that doesn't mean they hold the W3C to a guarantee of correctness on day one, or day infinity for that matter. Some organizations writing downstream specs that reference HTML5 will write|publish their own compliance test regimes that effectively (i.e., operationally) define what is correct as far as they are concerned. Such test regimes will also change over time. The point I was making by my input was that given correctness and test completeness versus timeliness, then the latter is more important to such organizations (assuming that W3C will backfill errors and inadequate test coverage over time). Of course, if it is a matter of mere months to do the first as opposed to years, then please proceed. But the discussion here has been a delta of years between a strict and a permissive approach. In this case, the market requirements are more important for producing a REC.
Received on Saturday, 18 August 2012 03:37:24 UTC