Re: Change Proposals, objections, and the Decision Policy

On 16.06.2010 09:16, Adam Barth wrote:
> ...
>>> 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.
> ...

It's a good thing when reviewers point out editorial flaws instead of 
ignoring them. It's a good thing when spec editors pay attention to this 
feedback. (I know you do, and thanks for that).

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

This doesn't need to be an exclusive "or", right?

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

I'd agree if these things were hard to fix. They aren't. Trivial things, 
once pointed out, should be fixed immediately; that's the best way to 
avoid additional work (more bug reports, more replies to bug reports) 
later on. This applies both to spec writing and software.

> We're not quite there with HTML5, but we're getting close.  These
> issues are way below the line of what matters.

If they do not matter to you, fine. They matter to others. If this is a 
bandwidth problem, let's assign a second document editor who will 
address things like these (and similar issues like vague references to 
other specs).

Best regards, Julian

Received on Wednesday, 16 June 2010 07:38:40 UTC