W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2016

[Bug 29708] New: [XP31] EQName production and spaces

From: <bugzilla@jessica.w3.org>
Date: Sun, 26 Jun 2016 17:50:47 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29708-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29708

            Bug ID: 29708
           Summary: [XP31] EQName production and spaces
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath 3.1
          Assignee: jonathan.robie@gmail.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

The current EQName production is:

EQName            ::= QName | URIQualifiedName
URIQualifiedName  ::= BracedURILiteral NCName    /* ws: explicit */
BracedURILiteral  ::= "Q" "{" [^{}]* "}"         /* ws: explicit */

In a lengthy discussion [1] it turned out not to be very trivial to find out
what happens if the URI inside the BracedURILiteral contains spaces. We say
about this:

   "The namespace URI value is whitespace normalized according to the rules 
   for the xs:anyURI type in Section 3.2.17 anyURI XS1-2 or Section 3.3.17 
   anyURI XS11-2"

The types in XSD 1.0 and 1.1 have whitespace="collapse", which means that
leading and trailing whitespace of the xs:anyURI value are removed. This makes
the following equal:

Q{http://www.w3.org/2005/xpath-functions/math }pi()
Q{ http://www.w3.org/2005/xpath-functions/math  }pi()
Q{http://www.w3.org/2005/xpath-functions/math}pi()

and the following indistinguishable:

Q{http://foo bar}test
Q{http://foo   bar}test

Currently, the first two above are rejected by Exselt and Saxon (as syntax
error for not finding the function fn:pi()). However, the status-quo of the
spec suggests this to be valid and equal (in Bug 29707 I requested some tests
to this effect).

Proposal:

I don't think the spec is broken. I do think we ought to say something about
this more explicitly than we do now (considering that two implementations seem
to have got it wrong).

Alternatively, disallow spaces in EQNames altogether, which will only disallow
a very small corner use case (spaces in namespace URIs, which are strongly
discouraged by the NS spec and cannot be used in quite a few applications).

[1] https://lists.w3.org/Archives/Public/public-xsl-query/2016Jun/0068.html
(and the mail thread before)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 26 June 2016 17:50:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC