[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
saxon:next-in-chain is a very convenient way of constructing a pipeline of transformations, but it's by no means the only way. Both the JAXP and s9api APIs, for example, are designed very much with pipelines in mind. There are also plenty of hooks available in Saxon to implement features like this yourself: for example, you could use xsl:result-document to send the output to a URL that includes the next stylesheet as a URL query parameter, and you could write an OutputURIResolver that detects this and fires off the next transformation.
Generally, I think for modularity and reuse it's a good idea to use one stylesheet per step in a transformation pipeline, rather than doing multiple steps within a single stylesheet. So I wouldn't encourage you down the route of combining the steps into a single stylesheet with multiple modes.
One of the motivations in getting rid of some of the extensions that had accumulated in Saxon over the years (not the only one, I admit!) was that there were often too many ways of doing the same thing.
On 26/07/2012 13:44, Emmanuel Bigui wrote:
Re: [xsl] next-in-chain
Subject: Re: [xsl] next-in-chain From: Michael Kay <mike@xxxxxxxxxxxx> Date: Thu, 26 Jul 2012 14:03:20 +0100 |
saxon:next-in-chain is a very convenient way of constructing a pipeline of transformations, but it's by no means the only way. Both the JAXP and s9api APIs, for example, are designed very much with pipelines in mind. There are also plenty of hooks available in Saxon to implement features like this yourself: for example, you could use xsl:result-document to send the output to a URL that includes the next stylesheet as a URL query parameter, and you could write an OutputURIResolver that detects this and fires off the next transformation.
Generally, I think for modularity and reuse it's a good idea to use one stylesheet per step in a transformation pipeline, rather than doing multiple steps within a single stylesheet. So I wouldn't encourage you down the route of combining the steps into a single stylesheet with multiple modes.
One of the motivations in getting rid of some of the extensions that had accumulated in Saxon over the years (not the only one, I admit!) was that there were often too many ways of doing the same thing.
Michael Kay Saxonica
On 26/07/2012 13:44, Emmanuel Bigui wrote:
Hello,
(My question concerns Saxon and XSLT core at the same time).
I developed extensions for OpenOffice Writer that do a lot of transformations on OpenDocument files (controls in Schematron, then reports in HTML, etc.) These extensions rely extensively on the proprietary Saxon extension next-in-chain that direct the output of a transformation to another transformation; it allows for very readable and modular code.
OpenOffice uses the last version of Saxon HE (called Saxon B at the time, I think) that included proprietary extensions. But if a future version of OpenOffice switches to a more recent version of Saxon HE (and of course it can only be Saxon HE) then the next-in-chain attribute won't be available and my transformations will break.
So here's my question(s): - is there hope that a future version of Saxon HE will include some version of "next-in-chain", for whatever reason (for instance, because "next-in-chain" would become part of the standard) - if not, what's the best way to rewrite a series of transformations chained together with next-in-chain? Is there a better way than using variables and modes (which can be a mess if the existing transformations already use modes)? Can the modification be done somewhat automatically (it's a compilation problem, and obviously that's what Saxon does at run time...?)
Thanks, Regards, EB
2012/7/13 Michael Kay <mike@xxxxxxxxxxxx>:Will there be an open source version of Saxon covering 3.0 Michael, presumably the HE variant?
No decisions yet. I will wait to see what happens in terms of conformance profiles, whether there is a natural subdivision of the spec that maps to product levels. I agree it's important to enable the non-paying part of the community to move forward, as they have a lot of influence on uptake.
I'm also keeping my options open in terms of support for 2.0 in future product releases (other than as a subset of 3.0). At present you only get 3.0 features if you explicitly ask, but it's becoming a bit of a pain maintaining two modes of operation, especially minor details like format-date() returning different error codes depending on whether 3.0 is enabled.
Michael Kay Saxonica
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] next-in-chain, Emmanuel Bégué | Thread | Re: [xsl] next-in-chain, Wendell Piez |
[xsl] next-in-chain, Emmanuel Bégué | Date | Re: [xsl] next-in-chain, Wendell Piez |
Month |
Keywords