[wbs] response to 'Publish HTML 5 update with or without warnings?'

The following answers have been successfully submitted to 'Publish HTML 5
update with or without warnings?' (HTML Working Group) for Henri Sivonen.



---------------------------------
Publish draft without warnings?
----
Do you support publishing this Editor's draft (i.e., without 
the additional warnings, also a.k.a. Ian's draft) as a Working Draft at
this time?



 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
I think we should just publish a snapshot of the draft Hixie is editing
whenever the W3C Process requires a heartbeat WD.




---------------------------------
Publish draft with warnings?
----
Do you support publishing this Editor's draft (i.e., with 
additional warnings, also a.k.a. Manu's draft) as a Working Draft at this
time?
In order to provide more useful feedback regarding which warning text
should not be considered controversial and thus, should be removed,
please follow the suggestions outlined in this email.


 * ( ) Yes
 * (x) No

Comments (or a URI pointing to your comments): 
I think the selection of warnings is too arbitrary to support. I would
support porting the WHATWG status marker data into the HTML WG draft in a
way that doesn't use scripting (to comply with pubrules).

REMOVE #urls

This warning is redundant, because the spec already says there's a willful
violation. The warning is also misleading, because "challenging" it doesn't
change requirements for compat with existing content.

REWORD #fetch

HTML 5 is now delegating to MIMESNIFF. The section in HTML 5 doesn't seem
to need an update if MIMESNIFF is edited.

REMOVE #misinterpreted-for-compatibility

The warning about the willful violation is redundant, because the spec
already says there's a willful violation (again, required for compat as
willful violations always are).

As far as I can tell, banning encodings that are problematic from the
security perspective or that contribute to gratuitous encoding
proliferation isn't controversial.

REMOVE #implied-strong-reference

I haven't seen evidence of this section being controversial. Normative
implementation advice is what a sufficiently detailed spec is!

REWORD #other-metadata-names

I don't agree that the sentence "The IETF, IANA and W3C have proven that
they are capable of operating these types of registries" can be presented
as a statement of fact using the word "proven" due to past issues with the
timely functioning of the IANA MIME type registry (consider video/mp4,
image/jp2 and image/svg+xml).

REWORD #microdata

I think it would be appropriate to note the immature implementation status
of microdata. However, I think it's inappropriate to use the microdata
section as a promotional soap box for RDFa. The note shouldn't make
forward-looking statements about RDFa or promote a present RDFa REC that is
inappropriate for text/html. It would be the clearest not to mention RDFa
at all and to focus on the implementation status of microdata.

REWORD #the-source-element

I think a note saying that a baseline codec would be good to have would be
appropriate. (Something like the note that was in the spec from December
2007 until recently.) However, I don't think the W3C publication should
repeat anyone's speculative patent concerns about other formats.

REWORD #alt

The past controversy has been about absent alt--not about blank alt. The
PFWG has sent a response to the HTML WG, and the response OKs absent alt
under certain conditions. The issues raised have been about
accessibility--not about "usability".

REWORD #the-head-element

In practice, microformat consumers ignore @profile, so it's inappropriate
to cite microformats as a reason to have it.




---------------------------------
What to publish?
----
Given that these documents differ only in the presence or absence of
warnings, how would you like the results of the poll to be interpreted?



 * ( ) I would prefer to publish all Editor's Drafts that have majority
approval as Working Drafts.
 * (x) I prefer to publish only the one Editor's Draft receiving the most
votes as a Working Draft.

Comments (or a URI pointing to your comments): 
The purpose of heartbeat WDs is to communicate to the community outside
the WG itself, and publishing multiple drafts with only differences in
informative statements fails at clear communication.


These answers were last modified on 11 August 2009 at 19:12:27 U.T.C.
by Henri Sivonen

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/40318/wd08/ until 2009-08-17.

 Regards,

 The Automatic WBS Mailer

Received on Tuesday, 11 August 2009 19:17:10 UTC