29702 2016-06-21 15:59:35 +0000 [XP31] Production rules in the text not unambiguous as a result of missing annotations 2016-07-11 22:19:45 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.1 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 editorial --- 1 abel.braaksma jmdyck andrew_coleman public-qt-comments oldest_to_newest 126813 0 abel.braaksma 2016-06-21 15:59:35 +0000 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 126864 1 jmdyck 2016-06-29 15:02:46 +0000 (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) 126865 2 jmdyck 2016-06-29 15:06:36 +0000 (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? 126867 3 abel.braaksma 2016-06-30 07:35:07 +0000 (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. 126870 4 jmdyck 2016-06-30 18:44:56 +0000 (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. 126876 5 abel.braaksma 2016-07-01 05:32:49 +0000 (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. 126881 6 jmdyck 2016-07-01 13:55:46 +0000 (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. 126933 7 andrew_coleman 2016-07-08 13:04:01 +0000 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. 126949 8 jmdyck 2016-07-11 22:19:45 +0000 To finish resolving this bug, I carried out the change proposed in point #1, and ignored point #3.