20642 2013-01-11 09:32:17 +0000 [FO30] non-hierarchic URIs 2013-03-12 16:14:23 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Working drafts PC Windows NT CLOSED WONTFIX P2 normal --- 1 tim mike liam public-qt-comments oldest_to_newest 81224 0 tim 2013-01-11 09:32:17 +0000 fn:resolve-uri makes reference to non-hierarchic URIs. I couldn't find a description of how to determine whether a URI is non-hierachic. I'm guessing that it is what Java describes as Opaque URIs, rather than requiring knowledge of the specifics of all possible URI schemes. Could this be clarified in the specification? 81227 1 mike 2013-01-11 10:16:22 +0000 The term "hierarchic" is used in the sense of RFC 3986, which uses the term extensively though it does not define it formally. RFC 3986 in its list of changes states "All references to "opaque" URIs have been replaced with a better description of how the path component may be opaque to hierarchy." Java is using the old terminology. I'm happy to add an informal explanation, e.g. hierarchic URI (in the sense of RFC 3986). 81231 2 tim 2013-01-11 10:42:34 +0000 (In reply to comment #1) > The term "hierarchic" is used in the sense of RFC 3986, which uses the term > extensively though it does not define it formally. I read through that, and it does refer to "base URI has a non-hierarchical path" but I couldn't point to anything obvious in the specification that identified that non-hierarchical paths meant URIs which match the path-rootless production. It's more obvious from the RFC 2396 production: absoluteURI = scheme ":" ( hier_part | opaque_part ) The text from RFC 3986: "For some URI schemes, the visible hierarchy is limited to the scheme itself: everything after the scheme component delimiter (":") is considered opaque to URI processing. Other URI schemes make the hierarchy explicit and visible to generic parsing algorithms." seems to indicate that the hierachic nature is dependent on the scheme. e.g. mailto is always non-hierarchic, http is always hierarchic. > I'm happy to add an informal explanation, e.g. hierarchic URI (in the sense > of RFC 3986). Yes please - or a fairly specific reference into the RFC. Thanks. 81232 3 tim 2013-01-11 11:38:25 +0000 The text " A path consists of a sequence of path segments separated by a slash ("/") character. 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. " might lead one to believe that a URI is hierarchic if it contains a slash. Microsoft's .NET System.Uri class allows resolution against "opaque" URLs. Why does F&O forbid it, since an "opaque" URI is absolute? var urn = new Uri("urn:isbn:foo"); var mailto = new Uri("mailto:you@example.org"); var foo = new Uri(urn, mailto); Console.WriteLine(foo); // prints mailto:tim@cbcl.co.uk var bar = new Uri(mailto, urn); Console.WriteLine(bar); // prints urn:isbn:foo 81248 4 mike 2013-01-11 16:29:25 +0000 As regards your example, I think this rule: If $relative is an absolute IRI (as defined above), then it is returned unchanged. is intended to take precedence over this one: A dynamic error is raised [err:FORG0002] if $base is not ... a suitable IRI to use ... I agree that isn't necessarily clear in the spec. Is this what the issue is here? As regards the definition of a "non-hierarchic URI", I don't want to attempt to publish any kind of interpretation or clarification of the RFC: if timbl thinks it's a good enough specification, then it's not for me to say he's wrong. If there's more than one interpretation of what the term means, then I'm happy to say that you can use whichever one you want. The RFC states in 1.2.3 "...relative references can only be used within the context of a hierarchical URI", and we are merely referring to that statement, not attempting to amplify it. 81257 5 tim 2013-01-11 17:45:07 +0000 > Is this what the issue is here? No. My example was wrong. I meant to use "b.html" as one of the URIs. .NET does indeed through a (rather obscure) error when trying to resolve this against the URN. Just ignore all that! The issue is how to determine what constitutes a non-hierarchic URI. I'm guessing what Java identifies as Opaque URIs is one approximation. But I suspect it really boils down to how any specific URI scheme has been defined - and that's covered by scheme specific RFCs, not RFC 3986. In that sense, RFC 3986 isn't at all at fault. Were we to add the test: resolve-uri("b.html", "http:01234567890X") what result would you expect? 81267 6 liam 2013-01-11 18:29:38 +0000 Tim, yes, individual URI scheme registrations are responsible for saying whether a URI is hierarchical. I agree it's messy, and if a library decides to be over-optimistic and allow resolution of a relative URI against against, say, a mailto: URI, it's up to the user not to do that :-) - otherwise you'd be stuck when a new hierarchical scheme was defined that the library didn't recognise. 84297 7 tim 2013-03-12 16:14:07 +0000 The WG discussed this in Agenda 2013-03-05 and decided no change was to be made to the specification.