- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Tue, 21 Jun 2016 09:30:10 -0600
- To: "Abel Braaksma" <abel.braaksma@xs4all.nl>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, "'Public Joint XSLT XQuery XPath'" <public-xsl-query@w3.org>
On Jun 21, 2016, at 5:24 AM, Abel Braaksma wrote: > > >> -----Original Message----- >> From: C. M. Sperberg-McQueen [mailto:cmsmcq@blackmesatech.com] >> >> I think the whitespace rules of XPath say that this should be legal, >> since the grammar given in XPath is >> >> [117] URIQualifiedName ::= BracedURILiteral NCName >> [118] BracedURILiteral ::= "Q" "{" [^{}]* "}" >> >> and neither rule carries the /* ws:explicit */ annotation. >> >> So the new schema makes these values legal. >> > > I'm curious, where did you see the production *without* the ws:explicit? Because in XPath 3.0, 3.1 public CR and 3.1 internal CR I see the following production rules (under section A.2.1 Terminal Symbols, the inline rules in the body of the text do not carry the ws:explicit comments, which is perhaps a bit unfortunate): > > [117] URIQualifiedName ::= BracedURILiteral NCName /* ws: explicit */ > [118] BracedURILiteral ::= "Q" "{" [^{}]* "}" /* ws: explicit */ > > In other words, whitespace is prohibited for this production. I see the productions without ws:explicit at: http://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xpath-31-diff.html#id-basics http://www.w3.org/XML/Group/qtspecs/specifications/xquery-31/html/xpath-31.html#id-basics http://www.w3.org/TR/xpath-31/#id-basics But of course, I was relying on the productions in the text. The idea that constraints like ws:explicit should not be given in the text is new to me, and on the whole unwelcome. Is there a reason to omit them from the text? Thank you, Abel. Michael -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Tuesday, 21 June 2016 15:30:40 UTC