This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1856 - [F&O] Error FORG0009 seems redundant
Summary: [F&O] Error FORG0009 seems redundant
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-08-18 11:20 UTC by Colin Adams
Modified: 2007-02-25 23:41 UTC (History)
0 users

See Also:


Description Colin Adams 2005-08-18 11:20:45 UTC
I do not believe it is possible for this error to occur.

Because of:
"If $relative is an absolute URI reference, it is returned unchanged."
"If $relative or $base is not a valid xs:anyURI an error is raised [err:FORG0002].",

both $relative and $base are guarenteed to be valid URIs before the resolution
process starts, and relative is guarenteed to be a relative URI.
In which case, resolution cannot fail.
Comment 1 Michael Kay 2005-08-18 12:03:46 UTC
I think we put this in deliberately. IIRC, you raised an interesting point
previously about non-hierarchic URIs (for example, URNs); we were also concerned
about the fact that the xs:anyURI type embraces IRIs, whereas the URI resolution
algorithms in RFC2396 and RFC3986 only cover URIs.  We therefore decided to
leave the spec a little open-ended as to exactly which resolution algorithm is
used, and this also leaves open the possibility that such a resolution algorithm
is not defined over the entire domain of the xs:anyURI type.

Also, 3986 says that the base URI must be absolute, so if you use that algorithm
then you would probably expect to get FORG0009 if you supply a non-absolute base

We came to the conclusion that there's a lot of fuzziness in the infrastructure
here, and it's not our remit to sort it out.

Michael Kay
Comment 2 Colin Adams 2005-08-18 12:58:48 UTC
Fair enough.

but I'm intrigued about your point on a non-absolute base URI being supplied.
The spec says that the function expects it to be absolute.
So I was checking this first, and raising FORG0002 if this is not the case.

I guess this depends upon the wording "expects". To me, if a function "expects"
an argument to be X, then it is an error if it is not an X (in which case
FORG0002 is the most appropriate message).

And if it doesn't mean that, then I'm at a loss to know why it is mentioned at all.
If it is intended to allow a relative base for use with algorithms other than
RFC 3986, then I think the word expects should be dropped (or perhaps: "expects
$base to usually be .."
In which case, I would raise FORG0009 without attempting resolution, as I use
the RFC 3986 algorithm.
Comment 3 Ashok Malhotra 2005-09-27 15:46:04 UTC
The WGs decided on 9/27 to close this bug with the follwing resolution.

1. Replace the first sentence of the summary with "The purpose of this function
is  to enable a relative URI to be resolved against a absolute URI."

2. Convert the remainder of the summary into rules and add to the two existing
Comment 4 Jim Melton 2007-02-25 23:41:23 UTC
Closing bug because commenter has not objected to the resolution posted and more than two weeks have passed.