- From: Miles Fidelman <mfidelman@meetinghouse.net>
- Date: Mon, 26 Mar 2012 16:58:07 -0400
- CC: WebApps WG <public-webapps@w3.org>
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