Saxon

We've done a lot of work to allow customization of the error messages arising from schema validation, because we tend to assume those messages are likely to be directed to end users rather than developers. So the Invalidity object reported to the new InvalidityHandler interface does indeed include path information that can be used to identity the erroneous element in a tree.

For syntax errors in a stylesheet we tend to assume that the error message is destined either directly for the software developer, or for an IDE that uses the information to highlight the error in the source code. I find it a little hard to see how users who don't see the XSLT source code as XML markup are ever going to be able to diagnose syntax errors in that code. However, AttributeLocation has a property getElementNode() which (if available) returns the element node in the stylesheet tree, from which you could call Navigator.getAbsolutePath(), and use the resulting path to locate the corresponding element in your original DOM.

This won't work for run-time errors because we try to avoid any reference to the source stylesheet at run-time; this supports the strategy of allowing the compiled stylesheet to be exported and distributed as a free-standing SEF file.

For the next major release, I have introduced a configuration option Feature.RETAIN_NODE_FOR_DIAGNOSTICS. If set, this causes the AttributeLocation to retain a reference to the element node, regardless whether the error is static or dynamic. I think this will be generally useful to people doing custom diagnostics, including our existing IDE-vendor partners.