W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2015

[Bug 28011] Redefining RFC 2119 may and must

From: <bugzilla@jessica.w3.org>
Date: Sun, 15 Feb 2015 11:40:37 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-28011-523-ZkKS4stQVh@http.www.w3.org/Bugs/Public/>

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
A couple of additional points:

(a) The defined term "for compatibility" is never referenced as such; the
definition should probably be removed.

(b) Section 1.6.3 seems misplaced; it would make more sense to move it to 1.1

(c) I think it's inconsistent to say on the one hand that conformance rules are
defined by the host language, and on the other hand to use RFC (or RFC-like)
"must" language. I'm not sure we've ever really had a clear view on how much a
host language is allowed to modify the spec. One could argue that any spec can
choose to use parts of another spec selectively; if a spec A wants to
cherry-pick arbitrarily from a spec B, there is nothing that B can say to
prevent this. My feeling is that F+O DOES define conformance requirements
(functions must behave as described), but it is up to other specs whether to
adopt those requirements or not. 

A significant problem in switching to the RFC 2119 definition of "must" in F+O
is that we often use the word in sentences like "The primary format token is
always present and must not be zero-length." Here the requirement is not on the
implementor of the spec, but on the user. The correct reading of the RFC
definition is open to debate, but my interpretation is that it is always a
requirement on the implementation, and because it is defined as an "absolute
requirement" there is no room for discussion about what an implementation
should do ("raise an error") if the requirement is not satisfied.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 15 February 2015 11:40:43 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 15 February 2015 11:40:43 UTC