7

A warning is thrown whenever the same file is imported multiple times in an XSL transformation. Usually something along the lines of Stylesheet module file:/Users/blake/Documents/workspace/course-connect-parent/course-connect-publisher/src/main/xsl/config.xsl is included or imported more than once. This is permitted, but may lead to errors or unexpected behavior

However, it seems that if the same xsl needs to be imported by multiple 'children' xsl calls (say, a util.xsl containing important functions), this situation is unavoidable.

Is there a way to avoid these warnings, or a better way to do things?

Here is the problem setup:

FILE_A.xsl

imports FILE_B.xsl and FILE_C.xsl
uses functions/parameters from util.xsl, which it gets from FILE_B.xsl & FILEC.xsl
calls templates in FILE_B.xsl
calls templates in FILE_C.xsl

FILE_B.xsl

imports util.xsl
contains templates used by FILE_A.xsl
uses functions/parameters from util.xsl

FILE_C.xsl

imports util.xsl
contains templates used by FILE_A.xsl
uses functions/parameters from util.xsl

util.xsl

Contains functions/variables used by FILE_A, FILE_B, FILE_C
Riplikash
  • 843
  • 8
  • 27
  • You are using a "strange" XSLT processor. I am using XSLT for more than 12 years and have neve seen such a warning, though I use `` massively. Having the same stylesheet module imported more than once isn't an error at all. Simply ignore these warnings (or if they annoy you, change your XSLT processor). – Dimitre Novatchev Apr 11 '12 at 01:59
  • I'm using the latest version of Saxon, both in Eclipse and Oxygen. As one of the answers noted, it appears this is a 'feature' of Saxon. – Riplikash Apr 11 '12 at 15:53

2 Answers2

10

These messages are produced by recent releases of Saxon. It's not an error to import the same file more than once, but in some processors (including earlier releases of Saxon) it's very inefficient; it's also unnecessary, and it can make code very difficult to debug. Basically it means that you have multiple instances of the same template rules present with different precedences.

In XSLT, unlike other languages, a module doesn't need to have an import for everything it depends on. You only need one import anywhere in the stylesheet. 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.

I added the messages because of two incidents: one a user who was getting completely bizarre effects from xsl:next-match, the other a user who was getting pathologically bad compile-time performance because one module was imported combinatorially by about 100,000 different routes and therefore at about 100,000 different import precedences. There's always a tendency when a problem like this arises to try to ensure that it never happens again, and the warnings were a response to that, but like health and safety warnings it's hard to know when the balance is right. You can always ignore a warning if everything is working OK, and if you really want you can always suppress it by filtering messages in your ErrorListener.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • Ah, I see. I thought it was working more like c++ includes. That makes a lot more sense now. Thanks. – Riplikash Apr 11 '12 at 15:52
  • Actually, it looks like I'm still misunderstanding something. It sounds like you are saying if A.xsl imports util.xsl, B.xsl, and C.xsl, then B.xsl and C.xsl should have util.xsl available. But in Oxygen and Eclipse it reports an error in that situation. Imports seem to propagate up (e.g. from B.xsl to A.xsl), but not down. So if I place the import in A.xsl I get errors in B and C, but if I place the import in B and C I don't get errors, but I get the warnings (which I get I can ignore, but they still bug me). – Riplikash Apr 11 '12 at 16:02
  • oXygen (I don't know about Eclipse) allows you to declare that a stylesheet module is part of a group of related modules, in which case it no longer requires the module to valid as a standalone stylesheet. – Michael Kay Apr 13 '12 at 10:07
  • How can I suppress this warning when we invoke Saxon through the command-line? I tried -warning:silent (https://www.saxonica.com/documentation9.5/using-xsl/commandline.html), but it would suppress all recoverable errors/warnings, which isn't what I want, and it didn't work to suppress this warning. – Scott Mar 29 '22 at 14:58
  • As it says in the original answer, you can supply an ErrorListener (or in more recent releases, an ErrorReporter) to customise the output. – Michael Kay Mar 29 '22 at 15:04
  • I guess I am a bit confused. It seemed like ErrorListener (and ErrorReporter) needed to be used with Java. We invoke Saxon directly through the command-line, passing in the XSL and XML files. I can't seem to find an example of ErrorListener/Reporter being used in such a command-line only use case. – Scott Mar 29 '22 at 16:19
2

If you only use the stylesheets in that collection, i.e. never use FILE_C.xsl as a self-standing top level stylesheet, you can simply take the import of utils.xsl out, the imports have global scope so the templates in FILE_C.xsl will "see" the templates from utils.xsl even if that is imported higher up the import tree. The utils.xsl will only be imported once and the warning will go.

Alternatively you can leave things as they are, it is not an error and the system shouldn't really be bothering you with non-errors. Which XSLT system is that? perhaps it has an option to be less aggressive in its warnings?

David Carlisle
  • 5,582
  • 1
  • 19
  • 23
  • Maybe my editor just isn't working right, but it doesn't seem like imports propagate down, only up. If I import in A, B and C aren't aware of it. If I import in C and B, A is aware of it. Is that now how it should work? I'm editing in Oxygen and IntelliJ, btw. – Riplikash Apr 11 '12 at 16:04
  • editors don't always know (although I seem to remember you can tell oxygen) but that is the rules the editor may think you have undefined variables but it is wrong, ignore it and run it in xslt anyway:-) – David Carlisle Apr 11 '12 at 16:06
  • The XSLT processor lets you refer to variables, templates, etc, imported into any module in your stylesheet. But Oxygen doesn't know where the top-level module of your stylesheet is unless you tell it, which I think you can do by creating a project. – Michael Kay Mar 29 '22 at 20:27