next-in-chain

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