Support #5433
closed
xsl:import/xsl:include Hierarchy Methodology
0%
Description
My team invokes Saxon through the command-line by passing in the XSL and XML files directly. I am running into the same issue described here: https://stackoverflow.com/questions/10096086/how-to-handle-duplicate-imports-in-xslt#comment126656138_10102298
I.e. I am using import, but I am receiving complaints when I am trying to encapsulate my XSL files and thus end up with the same file imported more then once. Saxon produces a warning and returns an error code killing my build.
Suppress the Error
My first route was to try and use the command-line switch -warnings:silent. It was basically stated this isn't uncommon behavior:
It's true enough that if A.xsl uses util.xsl and you want to reuse A.xsl in lots of places, then it can be convenient if A.xsl declares its dependency using an import or include declaration, which means that if B.xsl also uses util.xsl you will end up with this situation of multiple imports.
However I still see the warning and the error code. It was recommended to use ErrorListener or ErrorReporter to suppress this error. But, I am unsure how this can be possible when we invoke Saxon through the command-line, and don't use any Java.
Avoid Multiple Imports of the Same File
I tried the use of the use-when attribute on the import, with a combination of static variables, dummy functions and elements; trying to emulate ifndef in C, but to no avail. XSL packages where also recommend as a potential solution, but I haven't found a concrete example/description of how they would help.
Is there any guidance on how I can either:
- Suppress the warning/error using a command-line setup that calls Saxon. Ideally only suppress this warning.
- Avoid the error using a different methodology (packages?), while maintaining encapsulation for scalability.
Updated by Michael Kay about 2 years ago
Firstly, I wouldn't recommend suppressing the warning. It is there for a good reason: having multiple imports of the same file at different precedence levels can lead to very subtle bugs, and is almost certainly unnecessary. I would certainly try to avoid the multiple imports in preference; but advising you how to do that would require detailed study of what is no doubt a rather complex application.
Packages in XSLT 3.0 were designed to solve these modularity problems, but I accept that they are complex and retrofitting them isn't going to be easy.
The -warnings option on the command line is no longer used, and it was only ever used to control the behaviour of what XSLT 1.0 called "recoverable errors" - which were run-time errors rather than compile-time warnings. The concept of recoverable errors has disappeared in XSLT 3.0 (and was only residually present in 2.0).
There are two ways you can configure a user-defined ErrorReporter or ErrorListener when running from the command line. You can use a configuration file with the option global/@ErrorListener, or you can write an initialization hook supplied by the -init option. Both approaches, however, require you to write some Java code.
I would have thought that using static parameters and @use-when attributes would provide a practical solution. Perhaps it would be a good idea to pursue this further. You haven't said why it didn't work.
Updated by Michael Kay almost 2 years ago
- Status changed from New to Closed
Closing this because there has been no follow-up to our reply, so we assume the question is answered.
Please register to edit this issue
.