Re: informal survey - on spec philosophy

Glenn Adams wrote:
> It has been stated to me that, at least for "open web platform 
> standards", the following statement is true and is shared by the 
> majority:
>
> "if it isn't written in the spec, it isn't allowed by the spec"
>
> I happen to disagree with the truth of this, based on my personal 
> experience both with spec writing and with implementation/use of 
> specs, but I would be curious to see who agrees with this idea or not.
>
> The case in point is an instance of a possible ambiguity in a spec 
> because a particular assumption/convention is not documented; i.e., an 
> assumption that something isn't allowed even though it isn't 
> explicitly disallowed. While I agree it is, in general, impossible (or 
> at least impractical) to document all disallowances, I do believe it 
> is important to document important disallowances, particular when 
> there are concerns raised about spec ambiguity.

Is this not the normative language for W3C specs:
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 (see [RFC2119] 
<http://www.w3.org/TR/CSS21/refs.html#ref-RFC2119>). However, for 
readability, these words do not appear in all uppercase letters in this 
specification.

Seems to me that if there isn't a "MUST NOT" or "SHALL NOT" or "SHOULD 
NOT" - then the spec. is silent on the matter.  Now, whether that makes 
for good interoperability or not is a function of how clear the spec. 
and associated validation mechanisms are.

And then there's always the "be /strict in what you send/, /loose in 
what you accept/" rule of thumb.

Miles Fidelman




-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

Received on Monday, 26 March 2012 21:43:14 UTC