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
