[Bug 29381] New: [QT3] resolve-uri-28 expects error FORG0002, but seems valid according to RFC-3986

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29381

            Bug ID: 29381
           Summary: [QT3] resolve-uri-28 expects error FORG0002, but seems
                    valid according to RFC-3986
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3 & XPath 3 Test Suite
          Assignee: oneil@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

Section 5.1 of the RFC says:

   A base URI
   must conform to the <absolute-URI> syntax rule (Section 4.3).  If the
   base URI is obtained from a URI reference, then that reference must
   be converted to absolute form and stripped of any fragment component
   prior to its use as a base URI.

Section 4.3 has the production:

   absolute-URI  = scheme ":" hier-part [ "?" query ]

Section 3 has the productions:

   URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

   hier-part   = "//" authority path-abempty
               / path-absolute
               / path-rootless
               / path-empty

It furthermore has the following example:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose


Which imo clearly shows that a "non-hierarchic" URI has a hierarchic part. The
test tests the following expression:

    resolve-uri("b.html", "urn:isbn:01234567890X")

Since the algorithm described in 5.3 assumes a path separator of "/" and
removes the last part segment, here the path is "isbn:01234567890X", which must
be removed, resulting in the valid new URI:

   "urn:b.html"

I believe this to be the correct interpretation of the spec. I know that often
this RFC is considered fuzzy, and perhaps somewhere it allows to consider this
"not a valid base URI", but I can't find it, hence my argument that this test
should NOT raise FORG0002.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 19 January 2016 15:39:41 UTC