Subject: Re: [xsl] next-in-chain|
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Thu, 26 Jul 2012 14:03:20 +0100
Michael Kay Saxonica
(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