This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Reviewing the spec just now I noticed that XSD 1.1 part 1 (Structures) includes a citation for XSD 1.0 part 1 second edition in the list of normative references. Is there some subtlety here that I have forgotten about that means this is (a) necessary and (b) not harmful to the logical consistency of the spec? Or should it just be moved to the non-normative references? Or should it be deleted? Since I suspect that no one in their right minds could take it seriously as a normative reference, I am going to suggest that no change we make could affect anyone's review of the PR and propose that we class this issue as purely editorial.
Further information: The citation for XML Schema 2nd Edition appears to be an orphan: there are no references to it anywhere in the spec. Some other references in the list of normative references should probably be reviewed. Functions and Operators is referred to in connection with the evaluation of XPath expressions; the citation should probably say that only the specific portions referred to in F&O are normative parts of XSD 1.1, not the entirety of F&O. XDM is referred to in the same contexts. Must XSD 1.1 implementations be full conforming implementations of XDM? If not, the citation should say what parts of the XDM are normative parts of XSD 1.1. XPath 2.0 also needs a note saying that only the portions of XPath 2.0 mentioned as obligatory in XSD 1.1 need to be implemented by XSD 1.1 implementations, not all of XPath 2.0. XSLT 2.0 is referred to several times, always to the effect that implementations are not required to use the XSLT 2.0 transformations given in the appendix but may perform the same changes in other ways. I think the reference should probably be moved to the non-normative list. In Datatypes, the citations for XPath 2.0 and F&O should, I think, say explicitly that only the parts mentioned as obligatory for XSD 1.1 processors are normative parts of XSD 1.1 Part 2.
Agreed. I think that for a reference to be normative, there has to be a statement in the spec that defers to the referenced spec for an answer to a question that affects conformance. There are no such statements in XSD 1.1 that refer to XSD 1.0, therefore the reference is not normative, and therefore the entry in the bibliography has been editorially misplaced. The reference should not be deleted, since there are many places in the text where XSD 1.0 is mentioned non-normatively, usually to help readers by indicating what has changed. Rather, the places where XSD 1.0 is mentioned should be hyperlinked to the bibliography entry. >XPath 2.0 also needs a note saying that only the portions of XPath 2.0 mentioned as obligatory in XSD 1.1 need to be implemented by XSD 1.1 implementations, not all of XPath 2.0. I think that's a misunderstanding of what a normative reference is. Making a reference normative is an assertion that there are statements in this spec that refer to the cited spec, and that to determine whether a processor is conformant you will need to read the relevant sections of the cited spec. There's certainly no implication that a conformant implementation of X requires or includes a conformant implementation of Y.
Michael Kay writes in comment 2 There's certainly no implication [when spec X refers normatively to spec Y] that a conformant implementation of X requires or includes a conformant implementation of Y. I agree that that is the point, or one of the points, at issue. In some standards development organizations, the meaning of normative references is described in words which suggest at least to some readers (e.g. me) that they do have precisely the implication denied by MK. Many of the international standards on my shelf introduce their normative references with the following words or similar ones: The following standards contain provisions which, through reference in this text, constitute provisions of this International Standard. Until this morning I had always taken that to mean that any normative provision of the document referred to was a normative provision of the referring document, at least unless otherwise stated. Re-reading the sentence now in the light of MK's argument I see that it is also susceptible to a more selective interpretation: 'there are provisions over there which are normative over here', rather than 'all the provisions over there are normative over here'. (Implicit existential quantification rather than implicit universal quantification.) The IESG statement at http://www.ietf.org/iesg/statement/normative-informative.html also seems to be compatible with the existential interpretation (as well as, I think, with the universal interpretation): Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. The 6th edition (2011) of ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards (http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3146825/4229629/4230450/4230456/ISO_IEC_Directives%2C_Part_2%2C_Rules_for_the_structure_and_drafting_of_International_Standards_%282011%2C_6th_edition%29%28PDF_format%29_.pdf?nodeid=10562502&vernum=-2) prescribe that normative references should be introduced using wording which addresses precisely this issue: The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. The Foreword says that this wording was changed "to clarify that a normative reference may apply in whole or in part", which suggests that this is not the first time a group has run into this question. I have not yet located any statement in the W3C process document or publication rules that says what a normative reference does and does not mean. If we take MK's view of the matter, there is less work to be done, and the review I've just done of the meaning of normative references in ISO/IEC, IETF, and W3C spec suggests that his view is compatible with the words used to say what the phrase "normative reference" is supposed to mean. Since the other view is also compatible with at least some of the formulations, we may want to add introductory text to make the matter clearer for our spec, but I no longer think it's as urgent as I thought earlier today.
Resolved: MSM to circulate boilerplate to the WG and insert it if no objections. Resolved: identify where references to 2e should point from and fix.
A wording proposal intended to resolve this issue (and some others) is now at https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.ep35.html (member-only link) So I'm marking this issue as needsReview. (The WG didn't particularly want to see this again, but it was easier to include it in the proposal than to exclude it.)
Add a note explaining that starting namespace names with "##" is strongly discouraged Mark the tests as "queried" Take up whether or not to make this an erratum at a later time
The proposal mentioned in comment 5 has been adopted by the WG and integrated into the status-quo text of the spec.
The change mentioned in comment 6 has also been made.