Saxon

The information that goes into the error message is provided in a more structured form in the object that's passed to the ErrorListener or ErrorReporter. There are significant differences here between 9.9 and 10.0, designed exactly for the kind of scenario you are describing, so I would suggest not investing too much effort on 9.9 since it will need to be re-done for the later release.

Your particular example describes a static error in XSLT, and of course that's only one possible scenario; we've also tried to move towards greater consistency between the various APIs e.g. for XSLT, XQuery, and XSD processing.

In 10.0 the principal interface is the ErrorReporter, which has a single method:

void report(XmlProcessingError error);

which makes it easy to supply an ErrorReporter as a lambda expression, e.g. in XsltCompiler.setErrorReporter(). This new interface also makes the break from the JAXP ErrorListener where errors always had to be constructed as Exception objects, which involves quite unnecessary overhead. There are several different implementations of XmlProcessingError, and if you're taking this seriously you might want to do more than access the standard properties available in the interface (getErrorCode(), getLocation(), etc) and look into what's available from some of the implementing classes.

The standard ErrorReporter used on the command line simply formats up the information held in the XmlProcessingError object. I'd strongly encourage you to start with the structured information, rather than trying to extract it by parsing the formatted message (which is liable to change between releases). Of course you might well want to use the Java code of the StandardErrorReporter as guidance it's in package net.sf.saxon.lib.

One caveat is that the actual error messages are only exposed as strings. For example, the message "Attribute @bla is not allowed on element xsl:variable" is supplied as a single string, not as a structure containing the template ("Attribute %s is not allowed on element %s", "@bla", "xsl:variable"). That's not ideal if what you're trying to do is to localise the messages; but it's still a big step forward.

Thank you very much for your fast and detail answered. Indeed, the ErrorReported seems to be the best way to further prcosess error messages in a structured way as we plan to do. Many thanks again.