Tighten specification of error information document in p:catch

[galtm]

In the core specification document, Section 15.7.3. The Error Vocabulary describes a document that is available on the error input port of p:catch. Consider a user who wants to write automated tests for the error handling in their XProc code. A tighter definition of the error information document would benefit this user by making it:

• Easier to write the test, knowing with greater certainty what data format to expect instead of empirically learning what shows up.
• Less likely that they have to change the tests when switching to a different XProc processor or a different version of the same processor.

Specific suggestions:

1. Change "should" to "must" in the sentence, "In order to facilitate some modicum of interoperability among processors, errors that are reported on the error input port of a p:catch should conform to the format described here." The word should comes across to me as nearly a blank check for an implementer, creating a lot of uncertainty for the user.

2. For the code attribute of <c:error>, indicate that if the caught error possesses an error code, the code attribute of the error information document must provide the error's code. The p:error step requires an error code, and I think it's reasonable for a user testing their own error to want to verify the error code in their automated test.

3. For the attributes whose values are defined as EQName, reduce the variability in the way of expressing the value. Please, either specify a format that an implementation must use or indicate that a given implementation must document its own way of providing the value. What should the user see in the error information document if the error was produced by p:error whose code option is a URI-qualified name? If it's a prefixed name, should the user expect that the error information document also uses a prefixed name? Using the same prefix? If it's an unprefixed name, should the user test against Q{}my-local-code or my-local-code, or must their test be written to accommodate both possibilities? (You might also consider providing EQNames not as attribute values but as element names or attribute names, so that users can use the node-name XPath function to obtain a QName item that's ready to be compared with an expected QName.)

4. Clarify what it means for the attributes of <c:error> to be optional, especially the name, type, and code attributes. If it's difficult for an implementation to provide certain information in the way an end user might reasonably expect (e.g., because something has already been optimized away), should the implementation provide whatever it has available or omit the attribute? I've seen cases in both XML Calabash and MorganaXProc where c:error/@name wasn't literally the name attribute of the step that failed, and I don't know whether these are bugs (i.e., not what the implementer intended) or just things that surprised me because I had the wrong expectation.

Thanks for considering this!