This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the absence of deeper knowledge in this, I do a feature request: XPath 2.0 have, as per "2.3.2 Identifying and Reporting Errors", a thorough description of errors: the structure of the error identifier is explained, and errors have assigned a namespace. I find the description of the identifiers informative and gives a background which hence has an pedagogical role. It also brings meaning to the codes, instead of being arbitrary strings. The namespace allows implementations to swiftly identify errors, in my opinion. XSLT 2.0 have no namespace, and no description of how the error codes are constructed, when considering for example section "E Summary of Error Conditions (Non-Normative)" and "2.9 Error Handling". Here are the reasons I think exists for having descriptions and a namespace for error codes in XSLT: * It is practical and informative to have the structure of error codes described(as above). It would also be consistent with XPath 2.0. A user might want to understand an XSLT error code to the same degree as one from XPath 2.0; the languages are highly related. * Errors from XPath 2.0 have a namespace but errors in XSLT 2.0 have not, and the two languages are highly related. Without asserting that a namespace for errors is good, it can be concluded that whatever a namespace "adds" for XPath, is not added for XSLT. If a namespace is considered a bad idea, it can hence be questioned why XPath has one, if assuming the differences between the two languages can not justify it. I am personally of the opinion that a namespace would be of interest because I find namespaces more "exactly" defined than null-namespaces, and the inconsistency with XPath worries me for the "usual" broad reasons of inconsistency. References and background are according to: http://www.w3.org/TR/2005/WD-xpath20-20050404/ http://www.w3.org/TR/2005/WD-xslt20-20050404/ Cheers, Frans
Thanks for the comment. The conventions for describing error codes in XSLT are intended to be consistent with those for XPath, and they are intended to be in the same namespace. I shall probably respond to your comment by adding a pointer from the XSLT specification to the XPath specification. Personally, I must admit to some ambivalence on this. Although we have structured the error codes as 8-character codes with fixed-size subfields in the good old COBOL/punched-card tradition, I would hate to see anyone examining an error code to see whether columns 3-4 contain "DE". In fact, we haven't defined any interfaces that communicate error codes, so it's a little bit difficult to see where we should describe their semantics (if indeed they have any semantics). I have tended more to the view that the code is simply an anchor that designers of APIs can use to refer to an error condition if they choose to do so, and responsibility for defining properties of errors and interfaces for getting such properties belongs with the API specification. However, the XPath and XQuery specifications lean more towards setting guidelines and expectations for the API designers to follow.
I must admit that I did not think these error codes were in the XPath errors namespace (and I checked several times, as I actually report the namespace, along with the error code in error messages). And, after the recoverable status of several errors changed, I actually changed my code to look at those two letters, to see if an error was actually recoverable or not (I don't think this is a good solution though, and intend to review my code sometime).
The XSL WG agreed today that it has always been our intent that XSLT error codes should work the same way and should be in the same namespace as XPath error codes, and that we need to make this clear in our spec. The statement that the codes should be treated as "unprefixed QNames" (which by implication are probably in no namespace) is out of date, and should have been changed when it was decided to put system errors in a defined namespace rather than in the null namespace. I'll also add an explanation of the way codes were allocated. I'll change the status to FIXED when I have made the editorial changes. Please let us know if this resolution is not satisfactory. Michael Kay for the XSL Working Group
The relevant editorial changes have now been made, so the bug can be closed.