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 does not set an explicit default that all text is normative unless otherwise stated, as far as I can see, but this could be read to be the underlying intent. It does call out certain cases, like examples and notes, that are non-normative and some others that are normative. This baseline expectation needs to be stated, especially in light of the fact that particular sections are also marked (both!) normative and non-normative in their titles, while others are coy about their normative state. Compare for example sections 1, 3, Appendix A, Appendix I. In the absence of some explicit statement, it appears that I could pick and choose what is normative across a non-trivial swath of text.
This looks like an editorial issue but it needs WG discussion of our policy, so I'm marking it needsAgreement, not editorial.
Proposal: Main body of the REC is normative unless otherwise noted. Appendicies must be marked normative or non-normative individually. Approved.
In an effort to make better use of Bugzilla, we are going to use the 'severity' field to classify issues by perceived difficulty. This bug is getting severity=minor to reflect the existing whiteboard note 'easy'.
During the teleconference of 21 March 2008, the XML Schema WG adopted a wording proposal (the 'March 2008 omnibus proposal') which we believe resolves in full the issues raised in this bug report. The wording proposal can be seen at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni-200803.html (member-only link) A paragraph has been added saying that the text of the spec is, by default, normative, and listing some obvious exceptions. John, as the originator of the bug report, I hope that you will agree that the change shown in the wording proposal resolves this issues satisfactorily. If you do agree, please change the status of the bug report from RESOLVED to CLOSED; if you don't, please change it to REOPENED and let us know what's wrong. If we don't hear from you, we will after a decent interval (at least two weeks, but probably more in practice) assume that your silence implies consent.
I note that the text in 1.5 is somewhat different than the (approved) proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=5150#c2 in how it treats appendices. Since 1.5 does not distinguish, by definition it supplies a tie-breaker rule for the appendices whose title is not explicitly marked as comment 2 would have us believe they should be, i.e. D, F, G, H. I'm not quite sure what the effect is of making (via the tie-breaker) the list of changes since 1.0 in App G normative, but it seems like you might want to make G non-normative (e.g. some eevvill language lawyer could argue that App G lists all changes, so anything not specifically mentioned there must be jettisoned). I will re-open to get this fact in front of the right eyeballs, but if the wg is ok with it as-is I can live with that state too.
Thank you; it's may be good to have the tie-breaker rule, but it's also good not to need it. So I've drafted a proposal to add explicit labels (normative or non-normative) to the appendices that don't now have them. It will be bundled into some larger set of changes and go, in due course, to the WG.
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.