- From: David Cramer <david@thingbag.net>
- Date: Thu, 23 Apr 2020 01:30:46 -0500
- To: xproc-dev@w3.org
On 4/22/20 2:41 AM, Imsieke, Gerrit, le-tex wrote: > Hi David, > > On 22.04.2020 06:48, david@thingbag.net wrote: >> Greetings, >> >> I'm using p:load to load a doc and wrap it in a p:try/p:catch in >> XProc (Calabash 1.22). When the document is malformed or unparsable, >> I get very little information about the nature of the problem in the >> catch: >> >> <c:errors xmlns:c="http://www.w3.org/ns/xproc-step"> >> <c:error xmlns:err="http://www.w3.org/ns/xproc-error" >> code="err:XC0011" >> href="file:/path/to/pdf.xpl" >> line="6" column="65">Could not load >> /path/to/Quinoa_Axe_Throwing_Specification.xml >> (file:/path/to/pdf.xpl) >> dtd-validate=false</c:error> >> </c:errors> > > This error message is probably already as detailed as it gets, given > that a program that uses an XML parser API does not see any difference > whether the file is malformed or non-existent. It would be super useful if I could tell them whether the parsing of the file failed because of an unresolved entity and an unclosed tag. The parser certainly knows that--it shows up in the "Underlying exception" in the stack trace: "lineNumber: 9; columnNumber: 55; The entity "foo" was referenced, but not declared". Couldn't the xproc parser put that stack trace in a c:error and let me deal with it? After all, I'm using a try/catch because I want to catch exceptions. If Calabash catches one from the parser, it can just throw it to me in the pipeline. I'll open a ticket against Calabash about that. >> >> Likewise, when I wrap p:include in a try/catch, I only get an error >> code indicating that it couldn't load a file and line numbers in the >> xpl: >> >> <c:error href="file:/path/to/library.xpl" line="18" column="34">XProc >> error err:XD0011</c:error> > > That’s another story. I agree that the message should contain all the > information that you see without try/catch. > > I filed an issue: https://github.com/ndw/xmlcalabash1/issues/303 Thanks for doing that. Due to the recursive nature of xincludes, it's important to give the user a clue about what file it was trying to open. >> >> There's no information about which file or files couldn't be loaded >> for example. >> >> I was attempting to have the pipeline package up the error >> information about why things fail and report it in a friendly way to >> my users. If I were to load the same document as the source for the >> pipeline and not use try/catch, Calabash would give me more >> information about why it failed to parse the document, which xinclude >> couldn't be resolved, etc but when I do that I have no way to recover >> gracefully from a failure within the pipeline. >> >> Am I going about things the wrong way? It seems that I have to put >> this code in the layer that calls Calabash and scrape the >> unstructured stderr/stdout info to let the user know what went wrong. > > My experience with Calabash is also that it sometimes omits > interesting parts of error messages. This is particularly the case if > you run p:xslt. If you run Saxon standalone, you will get much more > detailed error messages. The messages that Calabash displays are often > misleading (often some info messages previously emitted by the > stylesheet, but not the one that comes with the error). This might get > worse when wrapped in p:try/p:catch. What you report about try/catch > might or might not be related to the XSLT issue that I mentioned > (since Calabash uses Saxon’s APIs for almost all lower-level > operations, it might be related). > > There’s already another error about accumulating messages in > iterations: https://github.com/ndw/xmlcalabash1/issues/259 > Given Norm’s busy schedule, there is not much hope that he will be > able to fix it soon. But compared to a couple years ago, Calabash’s > diagnostic messages have already improved. I'm less worried about xslts because I can already handle errors inside the xslt, write out a helpful report on a secondary port, and terminate the pipeline later based what's in that report and after I've accumulated all the errors I can reasonably find. To the degree possible, I want to avoid forcing the user to run the pipeline, stop on the first error, fix that, run it again, stop on the next error, etc. > > You might try Achim’s processor, Morgana XProc, either in the XProc > 1.0 or in the XProc 3.0 beta version. > https://www.xml-project.com/ > Morgana has had more detailed error messages for quite some time. > > Both implementors, in particular Norm, have pledged to make error > messages (more) user friendly in the XProc 3.0 versions of their > processors. Thanks, I'll experiment with Morgana. Looking forward to XProc 3.0! Regards, David
Received on Thursday, 23 April 2020 06:31:01 UTC