Re: Bug 7034

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.

Received on Monday, 22 March 2010 15:29:29 UTC