[Bug 28011] Redefining RFC 2119 may and must

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28011

--- Comment #8 from Michael Kay <mike@saxonica.com> ---
I propose to resolve these issues as follows:

(a)/(c) I propose to retain local definitions of the terms "must" and "may"
rather than simply deferring to RFC2119. The RFC definitions, as pointed out by
MSMcQ, are too imprecise to be useful in the context of this specification
without elaboration. However, I intend to add a non-normative reference to the
RFC. Specifically, I propose using the following definitions:

* The auxiliary verb MUST, when rendered in small capitals, indicates a
precondition for conformance.

** When the sentence relates to an implementation of a function (for example
"All implementations MUST recognize URIs of the form ...") then an
implementation is not conformant unless it behaves as stated.

** When the sentence relates to the result of a function (for example "The
result MUST have the same type as $arg") then the implementation is not
conformant unless it delivers a result as stated.

** When the sentence relates to the arguments to a function (for example "The
value of $arg MUST be a valid regular expression") then the implementation is
not conformant unless it enforces the condition by raising a dynamic error
whenever the condition is not satisfied. 

* The auxiliary verb MAY, when rendered in small capitals, indicates optional
or discretionary behavior. The statement "An implementation MAY do X" implies
that it is implementation-dependent whether or not it does X.

Note: These definitions of the terms MUST and MAY are consistent with the
definitions in RFC2119, but expressed in language appropriate to the subject
matter of this particular specification.

(b) I propose to use small caps for rendering the formal instances of MUST and
MAY, as is done in the XSLT spec, replacing use of bold and hyperlink
rendition.

(d) Since MUST and MAY rely for their meaning on some notion of "conformance",
I propose to rephrase section 1.1 to include such a notion. In particular I
propose to be more precise about the freedoms available to a host language:

* This recommendation contains a set of function specifications. It defines
conformance at the level of individual functions. An implementation of a
function conforms to a function specification in this recommendation if all the
following conditions are satisfied:

** For all valid inputs to the function (both explicit arguments and implicit
context dependencies), the result of the function meets the mandatory
requirements of this specification

** For all invalid inputs to the function, the implementation signals (in some
way appropriate to the calling environment) that a dynamic error has occurred.

** For a sequence of calls within the same EXECUTION SCOPE, the requirements of
this recommendation regarding the STABILITY of results are satisfied (see
section XXX).

Other recommendations ("host languages") that reference this document may
dictate:

** subsets or supersets of this set of functions to be available in particular
environments

** mechanisms for invoking functions, supplying arguments, initializing the
static and dynamic context, receiving results, and handling dynamic errors

** a concrete realization of concepts such as EXECUTION SCOPE

** which versions of other specifications referenced herein (for example, XML,
XSD, or Unicode) are to be used

Any behavior that is discretionary (implementation-defined or
implementation-dependent) in this specification may be constrained by a host
language.

Note: Adding such constraints in a host language, however, is discouraged
because it makes it difficult to re-use implementations of the function library
across host languages.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 21 April 2015 08:29:00 UTC