This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As a result of [1], [2], [3] and [4] and the resolution in [5], caused by confusion about missing production annotations, the Joined WG asked me to write an editorial bug about improving the production rules that appear within the body of the specification. The issue at hand: the production rules within the text do not maintain the annotations in A.1 EBNF, which confuses competent readers. Proposal (my recollection of discussion in telcon #647) 1) Remove the following sentence from A.1 "To increase readability, the EBNF in the main body of this document omits some of these notational features. This appendix is the normative version of the EBNF." 2) Update the stylesheets such that the annotations become part of the productions within the text, so that they are normatively equivalent. 3) Leave section A.1 as the Normative EBNF. [1] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0047.html [2] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0049.html [3] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0053.html [4] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0056.html [5] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0057.html
(In reply to Abel Braaksma from comment #0) > > 2) Update the stylesheets such that the annotations become part of the > productions within the text, so that they are normatively equivalent. Done. This should be visible in the XPath/XQuery 3.1 specs the next time they're built+committed. It will also affect two other 3.1-series documents if they're ever built again: -- Full Text 3.1 (in the production for Pragma) -- Update 3.1 (in the productions for FunctionDecl and FunctionCall)
(In reply to Abel Braaksma from comment #0) > > 1) Remove the following sentence from A.1 > > "To increase readability, the EBNF in the main body of this document omits > some of these notational features. This appendix is the normative version of > the EBNF." > > 3) Leave section A.1 as the Normative EBNF. But if A,1 is the normative EBNF, shouldn't we still say that it is?
(In reply to Michael Dyck from comment #2) > > > > 3) Leave section A.1 as the Normative EBNF. > > But if A,1 is the normative EBNF, shouldn't we still say that it is? Yes, I thought that was the idea. With "leave", I meant "leave it in as", i.e., keep the status quo that A.1 is Normative.
(In reply to Abel Braaksma from comment #3) > (In reply to Michael Dyck from comment #2) > > > > > > 3) Leave section A.1 as the Normative EBNF. > > > > But if A,1 is the normative EBNF, shouldn't we still say that it is? > Yes, I thought that was the idea. But point #1 says to remove the sentence that asserts that the appendix is the normative version of the EBNF.
(In reply to Michael Dyck from comment #4) > But point #1 says to remove the sentence that asserts that the appendix is > the normative version of the EBNF. It says: remove that sentence. And #3 says to leave the section in, as a whole. Since we only specify explicitly when it is non-normative (like with A.4), I don't think we need to overstate it when it is normative. If the productions in both text and this section are now equal, they can both be normative. Stating it is normative suggests that the in-line productions may be different. I think it is better to leave it out, but I can live with it either way.
(In reply to Abel Braaksma from comment #5) > > If the productions in both text and this section are now equal, > they can both be normative. Stating it is normative suggests > that the in-line productions may be different. That's fine with me. But it's not the impression I get from point #3.
At the meeting on 2016-07-05, the WG agreed to resolve this with the following action: Action 649-03: mdyck to resolve Bug 29702 at his discretion.
To finish resolving this bug, I carried out the change proposed in point #1, and ignored point #3.