30006 2016-11-16 21:41:42 +0000 [XP31] Ignorable whitespace (probably editorial) 2016-12-06 16:44:34 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.1 Candidate Recommendation PC Windows NT RESOLVED WORKSFORME P2 normal --- 1 abel.braaksma jonathan.robie jmdyck public-qt-comments oldest_to_newest 128193 0 abel.braaksma 2016-11-16 21:41:42 +0000 When trying to find out whether the production for cast as required a space between "cast" and "as" (I know it requires one, just wanted to see it written) I went through the following: 1) Reading section A.1 EBNF, which points to A.1.1 Notation, and hit a dead end. 2) Searched for "whitespace rules" and came to A.2.4 whitespace Rules, here ignorable whitespace is discussed which suggests (but does not specify) that whitespace is not required, because of the term "ignorable" and "may occur between terminals". 3) At this point I decided to lookup XML 1.0 EBNF whether that had anything conclusion. A dead end again. 4) Eventually I found A.2.2 Terminal Delimitation, where the correct rules are explained. I was wondering whether I) A.1.1, in its section on terminals, could point forward to the section on terminal delimitation (which is *not* in the same main section on EBNF, I mean, not under A.1). II) We could make the language under *ignorable whitespace* somewhat explicit to the fact that while whitespace is ignorable, it is often required to separate two symbols, even though we don't have ws-explicit everywhere. III) With, or as alternative to II, add a backward link under A.2.4 on ignorable whitespace to A.2.2, to signify it is often *not* ignorable. Or basically anything that removes the confusion I felt today (I am not saying the rules are wrong, I just think they are somewhat counter-intuitive or slightly lacking). 128288 1 jmdyck 2016-12-06 05:52:06 +0000 Yeah, in my opinion, the lexical level is kind of a mess, editorially speaking. I raised some points here: https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0036.html but didn't get any interest. I think we could do something along the lines you suggest. 128292 2 jonathan.robie 2016-12-06 16:44:34 +0000 In today's telcon, we voted to close this without change to the specification. It could be simplified, but it's not wrong, and most developers have been able to figure this out. We do not believe that this is worth doing at this point.