Hi Isabelle (and Bart),

Yes, at the least it looks like there is a "missing piece" in the CITI interface as far as being able to specify an option to have CITI run the new (Java-based) XSLT 2.0  transformation.

Bart having entered an RFE is the appropriate response.

As far as having xychange itself "sniff" the stylesheet to determine which type of transformation to run, I think there might be a good reason that XPP is not doing that.

As Bart mentioned running the V2 engine on a V1 stylesheet can give different results than the V1 engine, but it might be those different results that are desired (i.e. the user may want to use the V2 engine even though it's a V1 stylesheet). So XPP does not make any assumptions.

Another approach to address this that comes to mind is to follow the pattern being used with xychange itself, and to add something like an -xsl2 option to CITI (which would cause CITI to add the -xsl2 switch to all xychange commands it runs, with the assumption that all XSLT transforms being run by CITI would be using the same V1 or V2 engine).

Jonathan,

The official RFE is on its way (the ticket has been entered).
So time for me to explain why the -xsl2 option is not enough.

First of all in a chain of transformations one could have a mixture of V1 and V2 stylesheets.
Lets as an example take the case where you add an XSLT V2 stylesheet to an existing chain of V1 stylesheets.
Forcing the use of a V2 engine (using the -xsl2) option will issue a warning message for each V1 stylesheet.
Plus it could potentially give you different results than you had when you were using the V1 engine.
(not using the -xsl2 option is not good either as you need a v2 engine to run your v2 stylesheet).
So in this case it makes perfect sense to let xychange sniff out what engine it needs to use.
I would even say that in 99% of the cases around it would make perfect sense to let xychange sniff out what stylesheet to use.

But don't throw away that -xsl2 switch either. (just as a solution for the cases you mentioned)

I would even suggest adding an -xsl1 switch in order to give people the choice to force the use of a V1 engine (just to make sure we have all bases covered).

But it would be very very nice if by default xychange sniffs out what engine to use as this would be the correct thing to do in 99.9% of the cases.
For the remaining 0.1%, the -xsl2 or -xsl1 option could be used.
And yes this would mean a slight change in behavior but because the risk is very low and it makes our lives and the product a lot easier I would vote "yes, go for it"

Hi Bart,

Appreciate the information. Please make sure you add all of this information to your ticket so that CS will include it in the Service Request they enter for Engineering.

However, the scenario you describe is overly complicated and the XPP tradition is to handle the "simple" cases in a straight forward way and then give the user the ability to handle the "complicated" scenarios in other ways.

Your argument could also be made for just using xychange itself, as it is possibly running multiple XSLT transformations. However, XPP provides just the -xsl2 option as the "straight forward" approach and scripts can be used to handle the "complicated" scenarios.

So I expect that any response to your RFE would be to just handle the "straight forward" scenario with something like adding an -xsl2 option to CITI.

As you've already mentioned to Isabelle, using Perl (or some other scripting language) can be used to handle any "complicated" scenario.

But this is all just supposition on my part and not an official response to your RFE. Your RFE will have to be prioritized and evaluated in the way that is done with all such requests.

If it is not possible to adjust xychange so that it decides what engine to use .. then is there any merit in having a new option which tells xychange to pick the xslt engine based on the version indicator in the stylesheet?
say,    -xslauto

So if you just have 1’s, or just have 2’s, or have a mix of 1’s and 2’s, you don’t have to worry about adding –xsl2  to some of your xychange commands – you could just add   –xslauto   to all your xychange commands.

An –xslauto option on the CITI command could indicate the same engine choosing process for all xychange processes that CITI runs.

Update: Since it was obvious that we missed the need to be able to tell CITI to run the XSLT 2.0 transformation, we have added an -xsl2 option to citi for the next XPP 9.1.2 SP (with minimal impact on documentation and "new features" for a Service Pack). A hotfix for XPP 9.1.1 can be requested from support if it is needed.

For the next XPP 9.2.0 future core release we've done even more. The Release Notes and manuals for XPP 9.2.0 will contain all the details.

In summary, we've added a new Which XSLT engine for xychange procs? field to the ci spec, with values V1, V2, and auto (with V1 as the default). In addition to the -xsl2 option added to citi (in the 9.1.2 SP), new -xsl1 and -xslauto options have been added. The -xslauto option causes XSLT transformations to determine which V1 or V2 engine to run depending on the version declaration in a stylesheet. The -xsl1, -xsl2, and -xslauto options, if used with citi, will override the field in the ci spec.

An -xslauto option has also been added to xychange, and the commz.pl, proc-qcommz.pl, and proc-qcommtz.pl scripts (used with Autoprocessing). There's no need for an -xsl1 option for these programs since the (unchanged) default behavior is to use the XSLT 1.0 transformation.

The Use XSLT 2 check box on the Transform tab of the Export and Import Process Dialogs in PathFinder has been changed to a radio box with a three-way choice: Use XSLT 1, Use XSLT 2, and Automatic.

The reason for not making -xslauto the default behavior for citi and xychange is that the XPP tradition is to not change existing behavior if at all possible. Even though the risk of "breaking" something might be very low, if a customer had been running things successfully for many years and then things "broke" only because they installed XPP 9.2, then it might take quite some time to figure out why and we would rather avoid that situation from happening at all.