Re: Change Proposals, objections, and the Decision Policy

On Wed, Jun 16, 2010 at 12:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 16.06.2010 01:43, Adam Barth wrote:
>> ...
>> At this point, it appears that they way to influence the working group
>> is to raise a snowstorm of objections and hope some of them stick.
>> Just to pick the six highest numbered issues as examples:
>>
>> 1) ISSUE-101: "Spec reference for US-ASCII."  Does this matter at all?
>>  I think everyone reading the spec knows what ASCII is.
>> ...
>
> If it doesn't matter, why can't we point to something that indeed defines
> ASCII?

Dunno.  When editing specs, I tend to accept these sorts of trivial
comments.  Another point of view might be that accepting these changes
encourages more objections in the same vein.

>> ...
>> 2) ISSUE-103: "XML escaping in iframe/@srcdoc."  This is the
>> definition of an editorial issue.  Who cares how explicitly the spec
>> says which characters need escaping.  If we micromanage the editorial
>> process at this level, we'll be working on this spec for the next
>> thousand years.
>> ...
>
> I care, because the current text implies that HTML is super-easy, while
> XHTML is so hard that even the Working Group can't explain it.

So?  It's still micromanagement.  Are you here to defend the honor of
XHTML or to help advance the web?

>> ...
>> 4) ISSUE-107: "Politics in fallback example for plugin usage."  Again,
>> a completely editorial issue.  Whoever raised this issue doesn't like
>> some text in the spec that could be replaced with lorem ipsum and the
>> spec would be the same.
>> ...
>
> The normative part would be the same, but the spec in total wouldn't.
>
> Again, if it's "not important" why is it ok that the editor fights hard for
> no change, and it's not ok for others to try to change that?

See my response to your first question.

>> ...
>> 6) ISSUE-110: "Change Control for text/html-sandboxed media type."
>> This issue is entirely pedantic.  In some future world, there might be
>> some confusion about who the controlling entities are for text/html
>> and text/html-sandbox.
>> ...
>
> This issue *will* surface when we do the media type registration. Pretending
> it won't just delays a fix.

Then let's deal with the issue when it actually occurs.

> I agree that it's unfortunate that issues like these take so much time to
> resolve, but please don't blame it completely on those who happen to
> disagree with the current text.

With a project as large as HTML5, we'll never dot all the is and cross
all the ts.  It's just not feasible.  In many ways, it's like shipping
a piece of software.  At some point you need to decide that the
remaining bugs just aren't worth fixing and that it's time to ship it.
 We're not quite there with HTML5, but we're getting close.  These
issues are way below the line of what matters.

Adam

Received on Wednesday, 16 June 2010 07:25:46 UTC