This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29498 - [FO31] Some normative RFC 2119 MAY/SHOULD etc appear in non-normative Notes, RFC itself is not mentioned in conformance section
Summary: [FO31] Some normative RFC 2119 MAY/SHOULD etc appear in non-normative Notes, ...
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 minor
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-22 00:57 UTC by Abel Braaksma
Modified: 2016-03-22 09:29 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2016-02-22 00:57:47 UTC 
I'm confused about a few occasions where the RFC xxx of MAY, RECOMMEND, SHOULD etc appear in explanatory Notes. The intent may have been that the verbs should be taken as written in the RFC, but this conflicts with the Notes themselves being non-normative.

I'm not sure whether this is a big problem or not, but if possible, the Note should probably have the non-capitalized versions of these verbs and/or the Note, if meant to be normative, should not be a Note to begin with?

I found the following 8 items using the following query on the XHTML source, which may or may not be an exhaustive list:

//*:span[@class="verb"][ancestor::*:div[@class/contains(., "note")]]

1) 4.1 Numeric Types: "when casting from string to double the lexical form -0 *MAY* be converted to positive zero"

2) 4.1 Numeric Types: "though negative zero is RECOMMENDED."

3) 9.8.4.4 The language, calendar, and place arguments: "This is the convention that *SHOULD* be used when the requested calendar is OS"

4) 9.8.4.4 The language, calendar, and place arguments: "the conventions of ISO 8601 *SHOULD* be followed"

5) 19.1.2.1 Casting to xs:float: "Implementations *SHOULD* return negative zero"

6) 19.1.2.1 Casting to xs:float: "implementations *MAY* return positive zero in this case."

7) 19.1.2.2 Casting to xs:double: "Implementations *SHOULD* return negative zero for xs:double"

8) 19.1.2.2 Casting to xs:double: "implementations *MAY* return positive zero in this case."

Similar situations may have appeared in the XP31 text, but it uses different styles and tags for each normative MUST/SHOULD etc, as such it is much harder to query the XHTML. I tried the following to get the elements containing these texts and it returns 13 items, which I haven't checked by hand yet:

//(*)
[not(*)]
[upper-case(.) = ("MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY")]

----------------

Interestingly, XP31 references RFC 2119, XSLT references RFC 2119, as does XQuery, but FO31 does not mention it. I would assume that it "inherits" its reference from XP31, but perhaps repeating it in the Conformance section may be a good thing, esp. since there are about 219 official, tagged occurrences of these keywords.

Furthermore, the Conformance section in XP31 links to RFC 2119, and mentions "MUST", "MUST NOT", "SHOULD" and "MAY", but not "RECOMMENDED", "(NOT) REQUIRED", which are used in the normative prose.

I think that is an omission?
Comment 1 Michael Kay 2016-02-26 10:34:30 UTC 
The current situation was arrived at as the resolution of bug #28011 which was extensively debated.

The reason F+O does not reference RFC 2119 is that it does not use the words MUST, MAY, and SHOULD with their RFC meaning. Instead it uses them as defined in section
 
https://www.w3.org/XML/Group/qtspecs/specifications/xpath-functions-31/html/Overview-diff.html#conformance-terminology

Note that this section has been completely rewritten since the CR.

The essential difference is that the RFC 2119 definitions invariable place requirements either on a processor (a piece of software claiming conformance) or on documents (a piece of text that may or may not be valid according to the specification). In F+O we use them mainly to place requirements on the caller of a function ("the prefix MUST be declared in the in-scope namespaces"); and failure to satisfy a MUST condition is not a non-conformance issue, it is something that simply causes a function to throw a dynamic error.

In addition, it has long been a policy of the WG that F+O does not state conformance requirements; since RFC 2119 is all about conformance, referring to it would therefore be inappropriate.
Comment 2 Michael Kay 2016-02-26 10:38:22 UTC 
To add to this: the RFC definition of MUST is:

MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

Whereas the F+O definition is much more nuanced:

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.
Comment 3 Abel Braaksma 2016-03-01 17:21:20 UTC 
Following WG discussion of today, meeting #634, agreement was achieved to do nothing, except for a scan of the XP31 spec to remove or update any references that use spec-font, that are not in the conformance section.

Closing the bug, pending the action item.