This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1.5 Documentation Conventions and Terminology says in part: The following highlighting is used for non-normative commentary in this document: Note: General comments directed to all readers. Within normative prose in this specification, the words may, should, must and must not are defined as follows:... The qualification "Within normative prose" could be read to mean that when H9.MUST etc occur w/in non-normative text that their meaning is undefined, or that it reverts to its colloquial meaning. In several Notes however the context makes it appear that they are intending to assert normative requirements, which (by virtue of 1.5 stating that Notes are non-normative) is inconsistent. If their use in non-normative notes is allowed, either they should not be marked H9 or their interpretation should be explicitly declared in 1.5. This would have to be a global scrub. The ones I noticed are enumerated below. - 3.2.6, xsi: Not Allowed "but must not be declared." - 3.11.5, identity constraint table PSVI contribution "conformant processors may, but" - 3.12.4, Type Alternative Validation Rules, "processors may issue a warning " - 3.13.4, Assertion Validation Rules, "result of XPath evaluation must be" - 3.13.4, Assertion Validation Rules, "case they should be mapped to float."
This is in some sense an editorial issue, but I believe the WG needs to discuss our policy on the question, so I'm marking it needsAgreement, rather than 'editorial'. Without having reviewed the notes in question, I suspect that in at least some cases, the MUST/MAY/SHOULD language in the notes is intended as a summary or restatement of normative rules specified more formally elsewhere, or as a way of making explicit some consequence of the normative rules elsewhere. We'll need careful editorial thinking about the right way to solve this problem without either descending to confusing formulations or requiring clutter like "It is a consequence of rules specified elsewhere that ..." everywhere.
Actually I find that when you're trying to summarize or explain the consequences of some detailed rules, phrases like "The rules above ensure that..." or "In summary, ..." can be very helpful as an indicator to the reader that the material is in some sense secondary, even if it isn't technically non-normative.
WG has decided not to change the notes (i.e. keep caps where they are) but to improve the description (approved separately) of normative and non-normative sections to include a description of what caps mean in notes.
A wording proposal intended to resolve this issue is now at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5150b.html (member-only link)
looks fine
The wording proposal mentioned in comment #4 was adopted by the XML Schema WG on its telcon today. Accordingly, I'm marking this issue resolved. John, as the originator of the issue, I hope you will signal your assent to this decision by changing the status of the bug to CLOSED, or your dissent by reopening it. If we have not heard from you within the next two weeks or so, we will assume (encouraged by your comment #5) that silence implies consent.