Saxon

Legacy ID: #6470326 Legacy Poster: Michael Kay (mhkay)

This illustrates why "extension elements" have been renamed "extension instructions" in XSLT 2.0 - they can only serve as instructions within a template rule or function, not as top-level declarations. There's no extensibility point in the Saxon architecture that would allow the criteria for selecting the best matching template rule to be changed. You would have to subclass the Mode class, and there's no factory mechanism for doing that. Try it by hacking the source code if you think it would be interesting - but I can't really see why you would want to.

Legacy ID: #6478158 Legacy Poster: juangamnik (juangamnik)

We discussed that last year already ;). I generate several XSLT scripts from a graphical description. There is one main XSLT stylesheet importing all other, but the templates in the imported style sheets should be equal concerning the import precedence, because this way it matches the semantics of my graphical representation, where the order of imports in my generated stylesheets is irrelevant. Unfortunately I cannot use xsl:include, because there would be many duplicate top-level elements... It seems that I will have to "change" import precedence by manually setting modes reflecting my internal order of templates. That's a little bit complicated and not really fast, but I have no idea how to solve that problem. The only other way I could imagine by now, would be to include the "substylesheets" manually (via another xslt transformation) instead of using xsl:include or xsl:import and don't insert duplicate top-level elements.

Legacy ID: #6478218 Legacy Poster: Michael Kay (mhkay)

If you're generating the stylesheet then I would have thought it would be possible to generate code that follows the semantics of XSLT as defined. If duplicate elements are a problem, you can surely get rid of them.

Legacy ID: #6482954 Legacy Poster: juangamnik (juangamnik)

I'll try that.