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

Henri Sivonen wrote:
> 
>> Ian Hickson wrote:
>>> If the idea is to mark up all the issues where someone disagrees, then
>>> there are a number of other sections we should mark...
>>
>> The idea is not to mark up all of the issues where someone disagrees.
>> One of the ideas is to mark up the issues that seem to involve current
>> or potential disagreement in larger communities both inside and outside
>> of the WHAT WG and HTML WG (such as other W3C groups, IETF groups, or
>> other standards bodies).
> 
> It seems to me the idea of the draft is to deliver
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#microdata
> 
> The warnings seem rather arbitrary. They don't seem to reflect the 
> chair-maintained issue list nor do they seem to have any other common 
> theme that could be identified to form objectively-applied inclusion 
> criteria. I don't support the publication of a draft that seemingly 
> arbitrarily casts doubt over sections of HTML 5.
> 

I have similar concerns about the exact choice of warnings to those 
already expressed by Henri and Maciej. However I am fundamentally unsure 
what the purpose of this exercise is. I think the one issue that this 
group could come to immediate consensus on is that the spec has 
outstanding issues. Indeed at the top of the editor's draft it says:

"The publication of this document by the W3C as a W3C Working Draft does 
not imply that all of the participants in the W3C HTML working group 
endorse the contents of the specification. Indeed, for any section of 
the specification, one can usually find many members of the working 
group or of the W3C as a whole who object strongly to the current text, 
the existence of the section at all, or the idea that the working group 
should even spend time discussing the concept of that section."

So anyone reading the draft should be aware of the fact that it is not 
uncontroversial. What extra benefit is likely to arise by us spending 
time deciding on a process to mark some subset of all outstanding issues 
as "warnings" in the draft (something that is likely to be a 
considerable time sink as people discover that their pet issue doesn't 
make the cut and trying to tweak the criteria to meet their 
preconceptions), discussing the exact wording of those warning 
statements (which has already generated a non-negligible amount of 
additional email) and trying to reach the sort of temporary consensus 
that the group seems to require to do something as simple as publish an 
updated working draft? Unless you can convince me that this process will 
actually help us to resolve issues faster rather than just being another 
way to create process overhead and acrimony within the group, I think we 
should spend our limited resources on actually solving the issues we 
have rather than just finding yet another way to express the fact that 
some people prefer RDFa to Microdata.

More specifically, I see no point whatsoever in marking out issues that 
can be solved by purely technical discussions (e.g. garbage collection 
requirements, the <bb> element); historically there has been no 
difficulty in finding solutions to this type of issue.  It is generally 
only issues with a strong social component that have been problematic 
and I doubt that adding more red boxes will be an effective part of a 
solution process that will require people to be open to compromise and, 
ultimately, will require the group to be brave enough make some concrete 
decisions (by e.g. actually having polls rather than talking about maybe 
having polls) even though the results will leave some participants 
(maybe me!) feeling unhappy.

Received on Monday, 10 August 2009 09:35:03 UTC