I'd like to know if (and how) it could easy be done to write an extension element for saxon, serving as an alternative to xsl:import, evaluating the pattern precedence before the import precedence.
Greets,
Johannes Neubauer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to know if (and how) it could easy be done to write an extension element for saxon, serving as an alternative to xsl:import, evaluating the pattern precedence before the import precedence.
Greets,
Johannes Neubauer
I'll try that.
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.
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.
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.