xsl-list
[Top] [All Lists]

Re: [xsl] next-in-chain

2012-07-26 09:47:41
Hi,

One hastens to add to what Mike has said that in 2012, XProc shouldn't be excluded from any discussion of how to pipeline XSLT.

Of course if Open Office doesn't support it, it's not a solution for Emmanuel, but certainly (in part since open-source implementations of XProc are available in Java) it's something that the OpenOffice.org developers should consider. In other words, rather than simply upgrade to a version of Saxon that is more limited in some ways, couldn't OpenOffice (also) support input filters in XProc?

Then you'd get the equivalent to saxon:next-in-chain plus much else.

Cheers,
Wendell

On 7/26/2012 9:03 AM, Michael Kay wrote:

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 Bégué 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

--
======================================================================
Wendell Piez                            
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>