Re: HTML5-warnings - request to publish as next heartbeat WD

On Sun, 9 Aug 2009, Manu Sporny wrote:
> 2. Two other independent voices to support the publishing of this draft.
>    Without those voices, this proposal cannot be considered for
>    publishing.

I support publishing Manu's draft.

> 1. That this version is published as the next heartbeat
>    Working Draft. Specifically, this is not a FPWD since there are no
>    technical changes and thus there are no additional patent concerns.
> 3. A poll is created with two options:
>    [ ] Publish Ian's latest draft to address the heartbeat requirement.
>    [ ] Publish Ian's latest draft with Manu's warning language to
>        address the heartbeat requirement.
>    Whichever option that receives more than 50% of the vote will be
>    published. A tie will result in Ian's latest draft being published.

I would prefer to just publish both.


This warning is incorrect; the section has already been edited such that 
it no longer conflicts with the other specs; the relevant text has been 
extracted and is being edited by Larry in the IRI spec.


This warning is incorrect; the MIMESNIFF spec would not affect the 
fetching algorithm.


This warning may be correct (I don't know how much consensus this section 
enjoys), but the entire HTML5 effort is predicated on being accurate 
rather than politically correct, so it seems unlikely that the section 
will change for the reasons stated.


It's unclear what is controversial about this section. Could you 
elaborate? How else can we have interoperable behaviour without defining 
what references are present?


These warnings imply that these is the only aspects of the specification 
that have outstanding comments, but we have over 600 outstanding e-mails, 
issue markers, and bugs, so calling out a single set of issues from one or 
two such e-mails seems quite odd. For example, why not call out the 
"controversy" over whether <xmp> should have a U+000A line feed inserted 
after its start tag in the innerHTML serialisation algorithm? Or the 
"controversy" over whether we need a full-screen API or other mechanism 
for <video>? Or the "controversy" over whether we need a replaceState() 
method as well as a pushState() method? All of these are equally important 
issues that have outstanding comments.


Here I think we see the real reason you are doing this.


Actually "Origin" is renamed "Sec-From" and I just haven't gotten around 
to updating that part of the spec yet. It's not really controversial as 
far as I'm aware.


Reopening that issue seems unwise given the difficulty we had in reaching 
a compromise in the first place. However, if you do want to include such a 
warning, it's probably best to also say that having the attribute be 
included at all is itself quite controversial, and that the attribute 
might be removed altogether.

Incidentally, your document appears to remerge together multiple 
specfications that I thought we had established should be separate 
documents, like Web Sockets (indeed there is an IETF/W3C agreement that 
the protocol part of that shouldn't ever even be in a W3C spec), the SQL 
database stuff (which really _is_ controversial, though you don't appear 
to have noted anything to that effect), etc. Also, it seems your document 
has differences that aren't marked up, e.g. the introduction to offline 
Web apps is missing some of the examples.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 9 August 2009 20:08:19 UTC