Page 1 of 1

Sequence of transformations

Posted: Fri Sep 11, 2015 6:37 pm
by hlapin
Is there a simple, built-in way to pipeline two (only two, so I don't want to reinvent the wheel here) transformation scenarios in sequence, or does this need to be done in xproc?
In my use case, I want to convert ooxml to TEIP5, and then use my own XSLT transformation to modify the output. Selecting more than one transformation scenario always performs the XSLT transformation first, then the ANT transformation associated with OOXML document type.

Many thanks,

HL

Re: Sequence of transformations

Posted: Fri Sep 11, 2015 7:38 pm
by HomeGoods
Not sure which level of "built-in" you're looking for. Anyway I sometimes find a wrapper XSLT with saxon:compile-stylesheet() and saxon:transform() is easier and more portable than XProc.

Re: Sequence of transformations

Posted: Fri Sep 11, 2015 8:01 pm
by hlapin
Thanks!
I'm very new to this, so I'm probably missing something important, but since there is a stand-alone ANT process that must be done first and an follow-up XSLT transformation, I don't understand how to wrap the ANT transformation (and now that I think about it, how to do that with xproc either) using the saxon commands.

Thanks,
HL

Re: Sequence of transformations

Posted: Fri Sep 11, 2015 8:49 pm
by adrian
Hi,
hlapin wrote:Is there a simple, built-in way to pipeline two (only two, so I don't want to reinvent the wheel here) transformation scenarios in sequence, or does this need to be done in xproc?
The support for running transformation scenarios is not designed to chain transformations (as in a pipeline). The scenarios are basically run in sequence, but their order is not considered important since it assumes you are running independent scenarios with separate outputs.
For XSLT transformations, you can configure a single transformation scenario that chains several XSLT stylesheets via the Additional XSLT stylesheets button.

Since your initial transformation is ANT-based, have you considered doing this in ANT?
You could create your own ANT build file, call the build from your first ANT transformation, then run an XSLT transformation, then configure an ANT transformation scenario in Oxygen for your ANT script.

Regards,
Adrian

Re: Sequence of transformations

Posted: Thu Aug 08, 2019 7:09 pm
by dcramer
I guess this limitation only applies if you're mixing types of transformation scenarios (e.g. xslt and ant)?

The behavior I'm observing with respect to Ant transformation scenarios is that they are performed in the order that I click the boxes. I'm also able to put multiple target names in the "Build target" field as you would if invoking Ant from the command line and have those targets invoked in the order specified, but being able to tell users to click the boxes in sequence to perform preprocessing steps first is convenient.

It concerns me though to hear that by design the order in which transformation scenarios run is not considered important. Is the behavior I'm observing something I can count on remaining the same?

It might be worth adding a note about transformation scenario execution order to the documentation, perhaps here:
https://www.oxygenxml.com/doc/versions/ ... ion-dialog

Regards,
David

Re: Sequence of transformations

Posted: Wed Aug 14, 2019 6:23 pm
by adrian
Hi,
It concerns me though to hear that by design the order in which transformation scenarios run is not considered important.
The user interface is not designed to change the order of the associated scenarios. That should give away that the order of execution is not something designed to be set by the user. This feature (association/execution of multiple scenarios) was designed to provide the means to generate multiple types of outputs (rather than running them one at a time), but not for chaining. For multiple types of outputs the order isn't really relevant.
Is the behavior I'm observing something I can count on remaining the same?
I cannot guarantee that this behavior will absolutely not change, but it will most likely remain the same until the UI will be updated so that the order can actually be defined by the user (by design).
We can't document something that is not by design, and we would rather not encourage users to adopt something unless it is by design. You can consider using this behavior (order of clicked boxes) as a temporary solution for running scenarios in a specific order that works "as is".

Regards,
Adrian