[Bug 29381] [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

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I'm afraid we are using the wrong arguments here. Let me try to explain myself
better.

(In reply to Liam R E Quin from comment #2)
> (so no, you can't split a URN at a colon).
I am not suggesting we can. The first colon is not a path separator, it is part
of the scheme and separates [scheme] and [hier-part]. In a URN, [hier-part] is
the whole of the part *after* the scheme-colon, without any subsequent
splitting (I guess that is why in earlier specs it is called "opaque").

That's why I think that fn:resolve-uri("ietf:rfc:2648", "urn:isbn:0451450523")
should therefore return "urn:ietf:rfc:2648".


> Therefore, there's no such thing as a partial URI reference for a URN.
The URN itself cannot be split (except that some schemes have a hierarchy, like
DOI, but they are not standardized). But from the point of view from URIs they
consist of a scheme and a [hier-part]. The hier-part is opaque, but can be
split from the scheme and I think that is what RFC 3986 tells us.

(In reply to Michael Kay from comment #1)
> because RFC3986 is vague about these situations. It's
> true you can mechanistically apply the algorithm of 3986 to a non-hierarchic
> URI. But section 1.2.3 makes it pretty clear that you are not expected to do
> so: it says that some schemes are hierarchic and others aren't, and that
> "relative references can only be used within the context of a hierarchical
> URI". OK, that's a "can only" not a "must only", but it's all we have to go
> on.
That same section 1.2.3 also starts out by saying that all URIs are, by
definition, hierarchic:

   The URI syntax is organized hierarchically, with components listed in
   order of decreasing significance from left to right.  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.

So: "For some URI schemes, the visible hierarchy is limited to the scheme
itself".

Which I think sums it up... 

Whether all this makes "real world sense" I don't know, but I think it would be
a good thing to follow how other implementations (in this case: browsers*) have
been going about resolving URIs.

> I fear we will never converge on this one.
<snip>
> and the most I would accept in terms of the test case is to allow a 
> "success" result as an alternative result.
If consensus cannot be reached, then I would vote for that. But I hope we can
agree that absence of a "/" does not mean absence of a [hier-part] and that in
fact the URI spec is meant to be used orthogonally with any type of URI. 

-----
* Note that browsers that follow the HTML5 standard use the term URL, but
nevertheless point to RFC 3986, and further specify processing normatively in
https://url.spec.whatwg.org/, where non-hierarchical schemes are allowed and
resolve as explained above. However, different browsers, as they are, interpret
base URIs that are URNs differently.

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

Received on Thursday, 28 April 2016 00:47:28 UTC