W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: Bug 7034

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 22 Mar 2010 11:50:09 -0400
Message-ID: <4BA791B1.4010300@intertwingly.net>
To: James Graham <jgraham@opera.com>
CC: Henri Sivonen <hsivonen@iki.fi>, HTMLwg WG <public-html@w3.org>
On 03/22/2010 11:28 AM, James Graham wrote:
> On 03/22/2010 03:51 PM, Sam Ruby wrote:
>> On 03/22/2010 10:10 AM, Henri Sivonen wrote:
>>> On Mar 22, 2010, at 15:59, Sam Ruby wrote:
>>>
>>>> So what is the rationale for this restriction?
>>>
>>> I'll let Hixie respond to the question.
>>>
>>>>> When you talk about interop issues, do you mean actual interop
>>>>> issues with software deployed today (even if that software might
>>>>> fade away in the future) or interop issues in a future scenario
>>>>> where every piece of software conforms to the spec?
>>>>
>>>> If there are valid reasons to ignore a particular item, then a MUST
>>>> is not appropriate.
>>>
>>> If you push "valid reasons" hard enough, you can just do
>>> s/MUST/SHOULD/g and then validator UIs can label SHOULD violations as
>>> "errors".
>>
>> Fallacy alert:
>>
>> http://en.wikipedia.org/wiki/Slippery_slope#The_slippery_slope_as_fallacy
>
> I don't believe this is a fallacy. I write testcases in HTML all the
> time. Often in doing so I have valid reasons to ignore particular
> conformance requirements in the HTML specification — because, for
> example, I am testing the behavior of non-conforming documents —
> including those that are needed if authors want to achieve interoperable
> behavior in current UAs. When doing so I typically understand the full
> implications of what I am doing. Therefore per a literal reading of
> RFC2119 all author requirements ought to be SHOULD requirements.
>
> On the other hand, it is clear that RFC2119 was not really intended for
> expressing authouring conformance requirements. Various parts of the
> specification talk about vendors and implementations but nothing talks
> about authors. Given this, the incongruence between the precise RFC2119
> definition of the keywords and the way that they are used to express
> authoring requirements is rather unsurprising. So, from a spec-lawyer
> point of view the only way forward I see is to throw out the reference
> to RFC2119 and write some other document that defines the terms used for
> expressing normative criteria in the spec.
>
> However I think this is silly and misses the point.
>
> The only people who care about they way these terms are used are spec
> lawyers. I don't think that rewriting RFC2119 so that it more obviously
> applies to documents rather than implementations would have any
> noticable effects on document authors. In particular I see no difference
> between the validator reporting a RFC2119-style MUST as an error and
> whatever the replacement would be in a new document (even if it was
> closer to RFC2119-SHOULD); all that matters is that an error is flagged.
> I also believe that the current terms are relatively well understood and
> that the benefits of giving a consistent and relatively simple story to
> authors outweigh the benefits of being precisely accurate, especially
> when that accuracy is only appreciated by spec lawyers.

Whee!  Let's take a statement out of context and debate that.  No, on 
second thought, let's not.  Start here:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034#c32

"Not only is this an incorrect application of RFC 2119, as a strategy, 
it is entirely self-defeating.  Specs that contain such requirements 
will be willfully, flagrantly, and widely violated.  Furthermore, such 
requirements that have no basis in interop issues and describe 
situations that either authors or tools will commonly violate cause 
validators to produce volumes of spurious issues that only serve to 
obscure real problems."

Key. words. : "entirely". "self-defeating".

I submit as evidence:

http://html5.validator.nu/?doc=http%3A%2F%2Fwww.sina.com.cn%2F

Care to disagree?

I happen to believe that flagging all non-explicitly closed non-void 
elements is something that would be far more useful to authors of 
content intended to be served as text/html than flagging the use of 
unescaped ampersands in URIs is.

Care to disagree?

If I scream loudly enough (which seems to be the criteria that Henri 
believes has been applied to the spec to date), do I get to make this a 
conformance error?

I sincerely hope not.

- Sam Ruby
Received on Monday, 22 March 2010 15:50:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC