Saxon

We don't actually retain the form in which the filename was originally supplied; only the full absolute URI (and it would be a lot of effort to change this; in some cases, e.g. when the input is supplied as a StreamSource object, it's not even entirely under our control). The StandardErrorReporter abbreviates the absolute URI to the part after the last slash, because we reckon this is probably sufficient for users to easily recognise the file in the vast majority of cases, and outputting a full absolute URI would create too much visual clutter.

You can easily customise the StandardErrorReporter if you wish (you only need to override one method, abbreviateLocationURI()). Or if you want to access the information programmatically, rather than displaying it to users, it's all there in the Location object passed to the ErrorReporter.

Thanks for the suggestion, but I think I'm going to leave it as it is.

The error messages produced by default from the command line processor are designed to be read and interpreted by a human user, typically a reasonably knowledgeable developer. There are other interfaces that produce diagnostics more suitable for an application that is integrating Saxon processing into an IDE or into some other framework. Some of the customisation is also possible from applications based on the Saxon command line, for example by mechanisms including:

• the ability to supply a configuration file with -config

• the ability to supply initialisation code with -init

• the ability to nominate an error listener with --errorListenerClass (perhaps we should do the same with the new ErrorReporter)

• the ability to write a subclass of net.sf.saxon.Transform

I do think that if you're integrating with an IDE, you should be picking up error location information programmatically, rather than by parsing Saxon's formatted error messages, which are subject to change from one release to the next.

Yes, on reflection and from what you say, I should look into other options. Specifying an errorListenerClass looks especially appealing, at least for the short-term. Longer term, a dedicated VSCode Language Server would provide much better integration (and potential for a debugger etc.)

Regarding configuration, I found it relatively easy to set up a JSON Schema for this using VSCode. Specifying the XSLT configuration using JSON provides reasonable flexibility while ensured data-integrity, possibly also allowing integration with other VSCode extensions.

Currently a VSCode ProblemMatcher is configured to parse the XSLT processor's stdout using two admittedly rough regexes (one for each error-message line). The ProblemMatcher configuration specifies the regex capture group numbers to use to map to the VSCode ProblemItem properties. The regexes work reasonably well with Saxon 9.9 and 10.0, perhaps it was a little too easy, and I'm sure they don't cover all cases. So, there is a very good case for going for a dedicated errorlistener...as soon as I get time to put this together.

Philip Fearon wrote:

Yes, on reflection and from what you say, I should look into other options. Specifying an errorListenerClass looks especially appealing, at least for the short-term. Longer term, a dedicated VSCode Language Server would provide much better integration (and potential for a debugger etc.)

The way I've approached this for IntelliJ is to use reflection to load the Saxon instance from a path. I've created API wrappers around the Saxon API so I can call those APIs from the plugin, while handling API differences between saxon 9.2 and 10.0. Those wrappers are then used to implement the IntelliJ APIs for integrating into the IDE (running, profiling, debugging, etc.) -- I'm doing this via a plugin API to allow me to support multiple vendors, but you could implement the VSCode integration APIs directly using the Saxon wrappers.

If you are interested, the Java code for the Saxon integration can be found at https://github.com/rhdunn/xquery-intellij-plugin/tree/master/src/plugin-saxon/main/uk/co/reecedunn/intellij/plugin/saxon/query/s9api.