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

On Aug 9, 2009, at 9:38 PM, Manu Sporny wrote:

>
> 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.

It's currently my plan to vote against your proposed. If you're  
willing to revise it, you can gain my vote, it is up to you whether  
this is worth the effort. As far as I can tell, the proposal reflects  
your personal opinion and not any objective criteria, so I cannot  
personally endorse it at this time. I do think having no issue markers  
is better than having a poorly chosen set of issue markers based on a  
false sense of urgency. I can understand that not everyone will agree  
with my point of view.

> 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.

These are suggestions for a rule, not suggestions to apply to issues.  
So they are one step removed from deciding a set of controversial  
issues.

> So, please state clearly which issues you'd like to assert are not
> controversial and why they are not controversial.

If we can first agree on objective criteria, that would be easy.

> 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?

I haven't had time to do the research on any to be confident of that  
by my own standards.

>
>> 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?

Sorry, I meant to say "hasn't been replied to by the editor". <bb> is  
an example of something you marked "controversial". It hadn't drawn  
controversy before that time, and the feedback has drawn very few  
replies. I don't see how it can meet your informal "perma-thread"  
standard

>
>> 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.

With due respect, the fact that you marked this as "controversial"  
based on your own opinion, without even giving technical feedback to  
the list first, reflects poor judgment in assembling the list. How can  
something possibly be a "perma-thread" issue that's "controversial"  
when there has been no discussion? It's not even remotely appropriate  
for an issue to *first* be raised by suggesting a "controversial  
issue" marker in the spec.

As for the technical issue - there is absolutely no technical problem  
with this text. It gives normative conformance requirements that  
result in an observable difference in behavior, and that behavior is  
something web content counts on. It's for authors, not  
implementations. If you'd like further detail on the effect of this  
text I can explain, but that should probably go in another spec.


>> 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.

That is why I think existing perma-threads should be the standard.  
There's really no need to predict future hypothetical perma-threads at  
all

> 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.

<bb> does not look even remotely likely to cause a perma-thread. In  
fact, your text above explains why.


>> 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?

My rule is a set of qualifications for inclusion. I can say with  
confidence that the <bb> and GC issues definitely would not qualify,  
since they were raised very recently. I can also say with confidence  
that the alt issue would qualify, since I can find records of  
discussion going back with more than 6 months. I can say the same for  
the profile issue, since there is an issue in the issue tracker dating  
back more than 6 months.

Since you're not inclined to change your draft, I'm not going to do a  
rush job on the remaining research.

>
>> 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?

The Database section isn't missing in your draft, it's been added in  
your draft. 6.12.4.1 exists in your draft and not Ian's draft, and is  
a highly controversial section that was removed some time ago. I  
expect your script has some bugs in splitting and reassembling the  
document, so there may well be other unintended changes.

> 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.

Seems like overkill to me to vote on such a fine-grained basis, but  
it's up to the Chairs.

Regards,
Maciej

Received on Monday, 10 August 2009 07:31:25 UTC