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

Maciej Stachowiak wrote:
> On Aug 10, 2009, at 9:29 PM, Manu Sporny wrote:
>> Maciej Stachowiak wrote:
>>>> 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.
>>>
>>> I'd agree this can be defined as a "controversial" issue.
>>
>> Good.
> 
> Glad we agree on something!

We agree on more than you (and others) may seem to believe and I think
we're making good progress toward an objective approach.

> I believe that is the proper approach to such conflicts. I would add
> that it doesn't have to be the group raising the issue - an HTML WG
> member who is concerned about the conflict could raise it.

As long as we don't require that an external party to the HTML WG must
raise the issue, regarding specs external to the W3C, to have the issue
be taken seriously. If that is the mechanism, then I agree with you that
that is an acceptable way forward.

>> Minor concern: What happens if the WG that created the spec doesn't
>> exist in an official capacity anymore?
> 
> Then we need to do one of the following:
> 
> (a) Work towards a renewed effort that would create a successor spec.

This would be very time consuming, but would be the preferred way (IMHO).

> (b) Live with the conflict (many are, frankly, not harmful in practice),

I don't think this is a good solution -- even if the conflicts are not
harmful in practice, it's important that we keep the spec ecosystem
consistent.

> or, equivalently, consider ourselves to be writing a successor spec.
> (c) Match what the old unmaintained spec says.

I think this would work against moving the Web forward. To reiterate:
I'm fine with external specs needing to be changed, as long as those
external communities, if they exist, are heavily involved in the spec
change.

What I'm not okay with is the WHAT WG, via the HTML WG, decreeing
changes to an external specification without consultation and
collaboration with the external group. Especially if the external group
is hesitant to change the specification.

To apply theory to practice, I think WAI/PFWG are open to discussing
@summary, but the way WHAT WG approached the change was not productive.

Instead of raising the issue with WAI/PFWG and calmly discussing the
change with them in a non-combative manner, the change was placed into
the specification and shoved down the HTML WG pipeline. The WAI/PFWG was
forced to respond defensively, which didn't help to achieve what WHAT WG
wanted in the first place - for @summary to be
revamped/changed/reconsidered.

>> What I don't want us to do is sit by and let the language blind-side the
>> other working group or not allow anyone to raise the issue. I believe
>> that we should be rigorous in seeking feedback and gaining consensus
>> (both inside and outside the HTML5 community).
> 
> I totally agree with you on this. But I think HTML WG members are doing
> just fine at raising these issues. I don't think we have to go out of
> our way to label conflicts as "controversial" if no one has spoken up
> about the issue. If no one at all speaks up, that would mean the
> conflict is not, in fact, controversial.
...
> Frankly, I am dubious of the value of markers
> in the spec in the first place. Ultimately we have to actually resolve
> the issue, and stating that an issue is open in the spec does not
> directly do anything to resolve it.

So, I've seen this repeated several times now (more on WHAT WG's IRC
channel than this mailing list). I believe that there is confusion as to
why we need warnings in the document at all when they don't help to
actually resolve the conflict.

"Marking sections as under discussion" and "Solving the problem" are two
separate, loosely coupled, initiatives.

The first has to do with communication with the public web community.

The second has to do with resolving the issue.

The second item, "Solving the problem", will happen automatically
because of the W3C process you describe in your previous e-mail.

The first item, "Marking sections as under discussion", has more to do
with communicating the status of a section. The documents that we are
publishing via the HTML WG are a mish-mash of stable and unstable
features. There is no delineation between these stable/unstable sections
and thus the message that we are transmitting is vague at best and
misleading at worst.

Marking warnings on the sections under discussion was never about
resolving the issue (that will happen in time). It is about
communicating that there are a broad set of issues to the public without
listing every single issue.

The public is currently under the impression that HTML5 is right around
the corner because of the success of <video> and <canvas> - we need to
align the public's expectations with the current state of development.
That is the purpose of HTML5-warnings.

> As far as I can tell, we are not on track to LC in 3 months. To reach
> LC, we have to resolve all our controversial issues, and so far we have
> not been doing so. That being said, I think we should consider
> shortening the time horizon as we approach LC, if we ever actually start
> approaching it.

I don't think Ian shares that opinion. Perhaps he can clarify what he
means by HTML5 being on track for LC in October.

>> Since LC is a time for the public to review the spec, your criteria
>> doesn't allow any new sections of the spec to be marked with warnings.
> 
> As I understand it, these markers are for issues that are controversial
> within the WG itself. 

These markers are for issues that are controversial for HTML5, period. I
don't subscribe to this notion of something being non-controversial in
WHAT WG and controversial in HTML WG - the HTML5 ecosystem is about much
more than two working groups.

I also don't subscribe to this notion (that is echoed in the WHAT WG
IRC) that these are HTML WG problems and not WHAT WG problems. An issue
raised in the tracker is an issue for the HTML5 ecosystem (which
includes both HTML WG and WHAT WG). Failure to address those issues is a
failure of both HTML WG and WHAT WG.

> So if we must have them, I'd rather
> have it be based on reasonably objective criteria, rather than voting.

That's fine... and I agree with you in principle and perhaps even in
practice, now. I think with the changes you've mentioned above, we've
got a decent set of criteria for marking warnings in the HTML WG spec:

1) The issue was raised at least four months ago, by one of email,
   bugzilla or the issue tracker.
AND
2) There has been no mutually satisfactory outcome (the issue has not
   been closed).
OR
3) Any HTML WG member can raise an issue on conflicts between the HTML5
   spec and specs external to the HTML WG. External spec conflicts
   should be communicated to the public (ie: marked up in section
   warnings) immediately.

These rules assume that we're not going to go into LC for quite some
time (another 6 months, at least).

> That way, we can minimize the amount of time spent thinking about what
> to declare controversial, and spend more time thinking about how to
> resolve the controversy. I also note that the markers will not serve a
> useful purpose once we go into Last Call, since they all have to go away
> before LC and once LC is published we can't add any to the TR copy of
> the document.

Agreed.

I may spend some time figuring out how to tie the HTML WG issue tracker
to the HTML5 spec such that it is clear to readers if there are active
issues tied to particular sections of the HTML 5 spec. I believe that
may be the correct way to approach this issue. However, I still think
that we should publishing /something/ that has warnings in it.

I'll review which items meet the criteria above and see how the
HTML5-warnings draft would be changed as a result of the objective
criteria we've almost agreed upon. Let me know what you think of the new
set of objective criteria for determining whether a warning should be
publicly visible in the HTML WG draft.

-- 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 Tuesday, 11 August 2009 16:18:57 UTC