Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no path - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Feature #4516

closed

When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no path

Added by Philip Fearon over 4 years ago. Updated over 4 years ago.

Status:

Closed

Priority:

Low

Assignee:

Category:

Sprint/Milestone:

Start date:

2020-04-10

Due date:

% Done:

Estimated time:

Legacy ID:

Applies to branch:

Fix Committed on Branch:

Fixed in Maintenance Release:

Platforms:

Description

(With Saxon 10.0)

When invoking an XSLT from the command-line, if warnings or errors are emitted to stdout/stderr, I would like to be able to uniquely identify the source file location that is the cause of the warning or error. Currently, only the filename is given, not the absolute or relative path.

I'm proposing that the absolute or relative path is included in the file location for a warning or error message.

For example, with the entry-point XSLT:

<xsl:stylesheet
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    version="3.0">
    
    <xsl:import href="functions/basic-support.xsl"/>
    
    <xsl:param name="p1"/>
    <xsl:param name="p2"/>
    
    <xsl:template match='/'>
        <root>
            <xsl:sequence select="*"/>
        </root>
    </xsl:template>
    
</xsl:stylesheet>

If an error is found in the** imported** functions/basic-support.xsl, the result is, in a specific case

Type error at char 0 in expression in xsl:sequence/@select on line 10 column 47 of basic-support.xsl:
  XTTE0780  The required item type of the result of a call to ext:test#0 is xs:string. The
  supplied value is of type xs:integer
Errors were reported during stylesheet compilation

It would be most useful if the first line was instead:

Type error at char 0 in expression in xsl:sequence/@select on line 10 column 47 of functions/basic-support.xsl:

Files

problemEntries.png (201 KB) problemEntries.png

Philip Fearon, 2020-04-13 18:00

Actions

Copy link

Updated by Michael Kay over 4 years ago

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.

Actions

Copy link

Updated by Philip Fearon over 4 years ago

File problemEntries.png problemEntries.png added

OK, thanks for looking into this. The reason for this request was to allow any downloaded version of Saxon to integrate easily with the VSCode editor using an extension TaskProvider I'm working on without the need for an additional distributed command-line wrapper.

Right now, (as shown in screenshot) the command-line output from the XSLT processor provides VSCode with all the 'problem' data. The problem is that, if you click on the 'problem item', you would normally be shown the source XSLT with the problem highlighted, but when the source XSLT where the problem lies is in a different folder to the entry XSLT, an error message is shown instead. This message warns that the source file can't be found.

screenshot

Actions

Copy link

Updated by Michael Kay over 4 years ago

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.

Actions

Copy link

Updated by Philip Fearon over 4 years ago

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.

Actions

Copy link

Updated by Reece Dunn over 4 years ago

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.

Actions

Copy link