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

Maciej Stachowiak wrote:
> 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. 

Just to be clear - I am willing and intend to revise it after I know how
the HTML WG (via consensus) would like to have it revised. Revising
language (that isn't completely wrong/misleading, as some have pointed
out for @alt and #url) prior to the poll would just trigger an endless
cycle of disagreements on the revisions.

I am not willing to endlessly debate a set of inclusion criteria and
have meta-discussions on what should and shouldn't be included. Everyone
is going to have a different opinion on what should and shouldn't be
included - the only way to get some understanding of where the line is
is to have a poll.

We should focus on concrete proposals, not meta-discussions on selection
criteria for determining what is and isn't controversial.
What you are proposing, which I agree with in principle, could take
weeks of discussion to formulate into something actionable.

What I am proposing would give us broader community feedback by the end
of the week. If consensus finds in favor of Ian's draft and not
HTML5-warnings, that will be a clear sign that we need to have the
meta-discussion on selection criteria for what is and isn't controversial.

The poll is intended to collect more data on whether or not participants
in this WG would like to see warnings in the HTML5 spec. It is also
intended to gather data on which warnings are acceptable and which ones
are not considered controversial.

We can use that data to determine what does and does not constitute a
controversial section in the future.

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

I don't know how many people agree with your point of view and how many
people agree with my point of view. The easiest way to determine that is
to have a poll. Without feedback, both of us are just wildly postulating
based on our possibly flawed perception of reality.

I am asserting that we are in a quantum superposition with many
possibilities before us. One one of the fastest ways to get out of it is
to have a poll to see the actual points of contention.

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

Please state your concrete standards - we'll use those as a starting
point. I do not expect this to be resolved before the poll. The poll
should not wait for this to be resolved.

Here is a subset of my standards:

For a section to be determined controversial:

- It must have been discussed at length (for at least 2 months) without
  an agreeable solution being integrated into the specification.
OR
- It must contradict findings or language published by another working
  group (either inside or outside the W3C).
OR
- It must provide normative functionality that UA manufacturers have
  asserted that they will not support as-is.

While that doesn't constitute the entire line of reasoning that went
into the HTML5-warnings draft, it does provide a broad summary of how
the sections came to be marked as controversial.

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

That's because the perma-thread criteria wasn't applied to the <BB>
element, this one was:

- It must provide normative functionality that UA manufacturers have
  asserted that they will not support as-is.

> 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 will remove those sections if the poll asserts that those sections
should be removed.

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

I will change the draft when I can better understand where consensus
exists. If at least 25% of the voting body determines that marking the
GC and <BB> issues as not controversial, I will remove them.

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

This is Ian's source document that was used to generate the
HTML5-warnings document:

http://svn.whatwg.org/webapps/source

Here is its signature:

2009-08-08T15:29:36.000000Z
851346a717520ad6bdd0664b3a3e2e0a
2009-08-08T08:20:04.212170Z
3567
ianh

Here is the latest log entry:

------------------------------------------------------------------------
r3567 | ianh | 2009-08-08 04:20:04 -0400 (Sat, 08 Aug 2009) | 1 line

[e] (0) Clean up some references in preparation for actually having a
references section.

The database API section does exist in that document, which leads me to
believe that I may be using the wrong document? Search this document:

http://svn.whatwg.org/webapps/source

for this search string "<h5>Databases</h5>". You will find that it is
not removed. What am I doing wrong?

> I expect
> your script has some bugs in splitting and reassembling the document, so
> there may well be other unintended changes.

I had verified that the splitting script disassembled and re-assembled
Ian's original document byte-for-byte. I will double-check to ensure
that the assertion still holds and if not I'll fix the bug.

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

I'm not proposing that we vote on every single item. Voters can specify
which language they see as not controversial by specifying a removal
request for the fragment ids when they take the poll:

REMOVE warnings for #the-bb-element #implied-strong-reference

I think that's something that is fairly easy to measure and doesn't
require us to have meta-discussions on the philosophy of what
constitutes a "controversial issue" in order to determine what to mark
as controversial.

-- 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 17:21:47 UTC