[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

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
I fear we will never converge on this one.

The F+O spec states:

<quote>
A dynamic error is raised [err:FORG0002] if $base is not a valid IRI according
to the rules of RFC3987, extended with an implementation-defined subset of the
extensions permitted in LEIRI, or if it is not a suitable IRI to use as input
to the chosen resolution algorithm (for example, if it is a relative IRI
reference, if it is a non-hierarchic URI, or if it contains a fragment
identifier).
</quote>

Now, one can argue about all the three examples of "unsuitable" URIs listed in
the parentheses, 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.

We've made a conscious decision not to try to make resolve-uri any more
rigorous or prescriptive than the underlying RFC; the fact that the F+O
reference to non-hierarchic URIs is in parentheses is a deliberate choice,
because we recognize that it's legitimate to apply a different reading to the
words of the RFC. But I believe we made a conscious decision about this, and
the most I would accept in terms of the test case is to allow a "success"
result as an alternative result.

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

Received on Tuesday, 19 January 2016 21:01:10 UTC