Bug 4373 – [FO] resolve-uri() where $base is relative

Bug 4373 - [FO] resolve-uri() where $base is relative

Summary:

[FO] resolve-uri() where $base is relative

Status:	CLOSED FIXED

Product:	XPath / XQuery / XSLT
Component:	Functions and Operators 1.0
Version:	Recommendation
Platform:	PC Windows XP

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Michael Kay
QA Contact:	Mailing list for public feedback on specs from XSL and XML Query WGs

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2007-03-07 10:43 UTC by Michael Kay
Modified:	2007-11-16 09:10 UTC (History)
CC List:	0 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Michael Kay 2007-03-07 10:43:01 UTC

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.

Comment 1 Colin Adams 2007-03-08 07:51:20 UTC

Please see my additional comment to bug 684.

Comment 2 Michael Kay 2007-04-03 21:33:50 UTC

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.

Comment 3 Michael Kay 2007-04-16 21:27:18 UTC

The WGs today accepted the change as proposed. I am therefore closing the bug
report.

Michael Kay
for the XSL and XQuery WGs

Comment 4 Michael Kay 2007-11-16 09:10:28 UTC

This will appear as erratum FO.E1