This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification of resolve-uri() is unclear about what happens when the $base argument is itself a relative URI. At one stage the specification stated this was an error, and my recollection is that we made a deliberate decision to change this. However, the summary still states "The purpose of this function is to enable a relative URI to be resolved against an absolute URI", and the body of the specification states "and the resulting absolute URI reference is returned" (if $base is allowed to be relative, then the result will also be relative). The question was raised in a challenge to the published results of XSLT test case reluri19, which assume that resolving against a relative URI is permitted: see http://www.w3.org/Member/bugzilla/show_bug.cgi?id=684 (member-only) My proposed resolution would be to issue an editorial clarification to make it clear that $base is allowed to be relative, and that in this case the result will also be relative.
Please see my additional comment to bug 684.
The WGs reviewed this today. It was accepted that RFC 3986 makes it fairly clear that the algorithm it describes for resolving a "relative reference" (which we incorrectly refer to as a relative URI) is intended to take an absolute hierarchic URI as the base URI input, and to produce an absolute hierarchic URI as the result. I was asked to produce a concrete wording proposal for an erratum. Here is proposed wording: Summary: This function enables a relative URI reference to be resolved against a base URI to produce an absolute URI. The first form of this function resolves $relative against the value of the base-uri property from the static context. If the base-uri property is not initialized in the static context an error is raised [err:FONS0005]. If $relative is a relative URI reference, it is resolved against $base, or against the base-uri property from the static context, using an algorithm such as those described in [RFC 2396] or [RFC 3986], and the resulting absolute URI reference is returned. If $relative is an absolute URI reference, it is returned unchanged. If $relative is the empty sequence, the empty sequence is returned. If $relative is not a valid URI according to the rules of the xs:anyURI data type, or if it is not a suitable relative reference to use as input to the chosen resolution algorithm then an error is raised [err:FORG0002]. If $base is not a valid URI according to the rules of the xs:anyURI data type, or if it is not a suitable URI to use as input to the chosen resolution algorithm (for example, if it is a relative URI reference, if it is a non-hierarchic URI, or if it contains a fragment identifier) then an error is raised [err:FORG0002]. If the chosen resolution algorithm fails for any other reason then an error is raised [err:FORG0009]. Notes: Resolving a URI does not dereference it. This is merely a syntactic operation on two character strings. The algorithms in the cited RFCs include some variations that are optional or recommended rather than mandatory; they also describe some common practices that are not recommended, but which are permitted for backwards compatibility. Where the cited RFCs permit variations in behavior, so does this specification.
The WGs today accepted the change as proposed. I am therefore closing the bug report. Michael Kay for the XSL and XQuery WGs
This will appear as erratum FO.E1