This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28272 - [QT3TS] fn-resolve-uri-28, non-hierarchical uris, test should not raise FORG0002
Summary: [QT3TS] fn-resolve-uri-28, non-hierarchical uris, test should not raise FORG0002
Status: RESOLVED WONTFIX
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3 & XPath 3 Test Suite (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: O'Neil Delpratt
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-22 15:59 UTC by Abel Braaksma
Modified: 2015-04-01 23:06 UTC (History)
1 user (show)

See Also:


Attachments

Description Abel Braaksma 2015-03-22 15:59:17 UTC
Test fn-resolve-uri-28 expects error FORG0002 on resolve-uri("b.html", "urn:isbn:01234567890X"), but I can't find anything in http://www.ietf.org/rfc/rfc3986.txt that disallows that.

The URN fits the production of an absolute URI with scheme "urn" and path "isbn:01234567890X".

The algorithm in 5.2.2 skips to the merge(Base.path, R.path) line (non-empty R.path and not starting with "/"). The relevant part of the merge function (section 5.2.3) says:

  * return a string consisting of the reference's path component
    appended to all but the last segment of the base URI's path (i.e.,
    excluding any characters after the right-most "/" in the base URI
    path, or excluding the entire base URI path if it does not contain
    any "/" characters).

In other words, the path-part must be removed and the resulting URI will then be "urn:b.html". 

Uncommon, but not an illegal result. I doubt that this should raise FORG0002.
Comment 1 Michael Kay 2015-03-22 19:37:40 UTC
The current wording of the spec was introduced in Erratum E1 to the 2007 edition of Functions and Operators, and the discussion is reported in bug #4373.

I think that the test fairly reflects the decisions of the WG reported in that discussion. I agree that the term "non-hierarchic URI" is not very clearly defined (like many other aspects of URIs), but I think it means a URI in a scheme that uses a non-hierarchic path component, of which the "urn" scheme is the classic example.
Comment 2 O'Neil Delpratt 2015-03-31 14:23:44 UTC
I assume nothing should be done with this bug issue. Please reopen if you disagree
Comment 3 Abel Braaksma 2015-04-01 23:06:28 UTC
I think you are right. I mainly had a hard time finding out what a hierarchical URI is (in unambiguous terms), but after a couple of times rereading, I found this in the RFC:

   A path is always defined for a URI, though the
   defined path may be empty (zero length).  Use of the slash character
   to indicate hierarchy is only required when a URI will be used as the
   context for relative references.

Then I thought this still leaves schemes like palm:service/option1/option2 (apparently this really exists), which contain a slash and have a non-zero length path, but later I see:

   In addition, a URI reference (Section 4.1) may be a relative-path reference, 
   in which case the first path segment cannot contain a colon (":") character.

To conclude, it took me a while to grasp it, but it is all there, somewhere ;), and indeed, the test is good (and our results faulty).

As an aside, it was Oracle who defined it much easier:

   A hierarchical URI is either an absolute URI whose scheme-specific part 
   begins with a slash character, or a relative URI, that is, a URI that does 
   not specify a scheme. 

       -- from http://docs.oracle.com/javase/7/docs/api/java/net/URI.html