This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This problem exists in both the first and proposed second editions of F+O 1.0/2.0, and also in the draft F+O 1.1. What should be the error code if fn:doc is called to retrieve a document that does not exist, for example fn:doc('nonexistent.xml')? In one place we say "If the Available documents provides no mapping for the absolutized URI, an error is raised [err:FODC0005]." In another place we say "One possible processing model for this function is as follows. The resource identified by the URI Reference is retrieved. If the resource cannot be retrieved, an error is raised [err:FODC0002]." They can't both be right. Since this error is likely to be a common candidate for try/catch, it's important that we provide clarity about the expected error code. See also bug 868 in the member-only bugzilla, raised against the XSLT test suite on this issue.
The fn:doc error codes were discussed in Bug #7072.
This was discussed today. The sentiment is to use FODC0005 only for "invalid URI" and to use FODC0002 for failure to retrieve a resource and for failure to parse the resource as XML. Need to check that this is consistent with the latest situation for fn:collection (see bug 7072) and whether there are any references in the XSLT spec for fn:document. MK actioned to come back with proposed wording for an erratum.
The proposed changes are as follows: (A) In F+O for XQ 1.0, XP 2.0 In 15.5.4, change: If the Available documents provides no mapping for the string, an error is raised [err:FODC0005]. to If the Available documents provides no mapping for the string, an error is raised [err:FODC0002]. (B) Make the same change for F+O 3.0. (C) No changes are needed to fn:collection or to XSLT's fn:document function.
Although I don't have a reference to the minutes, my personal notes show this as having been decided probably in Dec 2010, accepting the changes in comment #3 (which have indeed been incorporated in the status quo text). This bug is therefore being closed as resolved/fixed.