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

Maciej Stachowiak wrote:
> I don't agree that this is a correct and reasonable set of
> "controversial issues". 

The definition of "controversial issues" that you are using is probably
different than some of the other definitions of "controversial issues"
that will be proposed in the coming weeks.

For example, some do not see willfully violating existing IETF or W3C
specs to be controversial if the violations are purely documenting
existing practice. While I fall into the category of people that are
sympathetic to this approach, I do also understand that violating a
standards body specification is a very controversial practice among
colleagues in the standards community.

"Controversial" is in the eye of the beholder - so coming up with an
ideal set of "controversial issues" in a working group this big is a
fools errand. Agreeing on a set of metrics will take weeks, if not
months. While I agree that we need to further define those metrics, I do
not think we should wait until that is sorted out for the heartbeat
requirement.

If, for the heartbeat requirement, people don't agree with the
HTML5-warning language so much that they'd rather not have any warnings
in the document, then they can choose to vote for Ian's document. I will
take that as a sign that the controversial markings in the draft were
completely off-base and we need to further define what constitutes a
"controversial issue" to the HTML WG.

That said, I do agree in principle to a number of your suggestions:

> (a) The rule has to have a reasonable relationship to what can be
>     considered a "controversial open issue"
> (b) The rule has to be reasonably objective.
> (c) The rule should not be so broad that it would apply to almost
>     every open issue.
> (d) It needs to be stated clearly what the rule is.

All of those seem fine, but they don't help whittle down the set of
currently marked issues.

So, please state clearly which issues you'd like to assert are not
controversial and why they are not controversial. If I made a mistake in
marking the warnings in the document (some mis-wording of the issues
have already been pointed out), I'll re-word it or remove it if there
are enough people that agree with you. I'm hoping that participants
should be able to provide feedback on which sections should not be
marked as controversial via the poll.

> Some of these are longstanding points of contention, it is true. 

Which issues that are marked are in that set, for you?

> Others are areas where the spec has already been changed 

The document I used was Ian's version as of yesterday at 6pm. I made
sure the problematic textual content existed in the spec before marking
up each issue. Could you please elaborate which of the controversial
issues have already been addressed?

> or is in the process of being changed to address concerns. 

Even if something is being changed to address concerns, if the
specification text has not been changed yet, and is controversial, I
marked it as such.

> Still others are very recent feedback that has not been raised to the 
> editor at all.

Could you be more specific, please? Which set of "controversial
markings" are you referring to?

> Still others have not been properly raised as feedback to at
> all. For example, I don't recall seeing any objections to the garbage
> collection section.

That's fair - I don't know if anybody has raised that as an objection
yet. I'd be surprised if the majority of the folks on this mailing list
would be okay with whatever that paragraph is attempting to achieve.

If it hasn't already been raised as an issue, I'm raising an objection
to that section right now because of the following reasons:

* It seems to provide normative implementation advice.
* It is not clear what the author is supposed to do with that specific
  bit of text? Does it mean that UA's must implement their reference
  counting code in a specific way?
* It is not clear if the term "implied strong reference" has any other
  implications to the underlying reference-counting implementation.

However, if folks are not concerned about this section, then I'm happy
to remove the warning language.

>> Manu Sporny wrote:
>> Basically, when I saw something that has or could trigger a perma-thread
>> discussion surrounding a feature (such as @summary did for the last two
>> weeks), I marked the feature as controversial.
>
> Maciej Stachowiak wrote:
> I agree with the sentiment, but I think you failed to successfully 
> identify the set of "perma-thread" issues. To pick some obvious
> examples, I can't see any basis for declaring <bb> to be a
> perma-thread (where there are a few very recent pieces of feedback
> and no debate as of yet)

Note that I said "that has or could trigger a perma-thread", not "has
triggered a perma-thread". Neither of us know if I've successfully
identified future perma-threads.

I marked <bb> because both Microsoft and Mozilla have raised fairly
strong concerns about implementing it in its current form and because
Ian has stated that he won't place anything in the final spec that
doesn't enjoy a 100% conformance rate among UA implementations.

> If you limit your list to open issues that have been unresolved for at
> least 6 months without meaningful progress (with reference to an issue
> tracker issue, or a mailing list post, dating back at least 6 months)

So, which items would this set of rules qualify for removal?

> and if you remove the other (seemingly unintended) technical differences
> from Ian's draft (such as adding back the Database section)

Any technical differences are purely accidental and completely
unintended. There may be a bug or two in the script I wrote to split
apart Ian's document. Which database section is missing, specifically?
Are there any other sections that are missing?

So, to summarize - I won't make any changes while the poll is happening.

If it's okay with the Chairs, any changes after the poll but before
publishing, will be a reflection of warning section language that at
least 25% of the voting members have requested to be removed or modified.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Monday, 10 August 2009 04:38:57 UTC