XSL 1.0/2.0+ usage on XPP

We are having problems maintaining the old "C++" version  of the program "Xalan" for XSL 1.0  processing. This program is triggered through "xychange" when the command line does NOT contain the "-xsl2" option, as we use the default behavior to preserve XSL 1.0 processing.  Since it is a program, it can also be used in scripting by calling "Xalan" directly. In my opinion, no one should be using XSL 1.0 at this point since it is has been far exceeded by 2.0/3.0 with very awkward work arounds for very common transformations and other transformations that are just not possible. The functionality has been replaced by the program "xppxslt",  which uses the Saxon parser, but requires Java.  Saxon is upwards compatible and XSL 1.0 transforms will run as is.

If you are doing XSL processing on XPP, I would like to know:

1. Are you installing Java and running with XSL 2.0+ functionality?

2. Are you calling the program "Xalan" directly in your scripts

3. Can XPP change the requirements to state that you need Java if you are doing any XSL processing at all?

With this in mind, in a future release we would:

1. Stop delivering "Xalan", but leave it on any system so custom scripts would still function.

2. Change "xychange" to automatically use the xppxslt/Saxon processor with or without the "-xslt2" option.

3. Change the requirements documentation to state that Java is required if doing any XSL processing. NOTE: Java is already required if using SVG or the 'xppcompare' program.

Thanks

Steve Piercey

RWS/SDL/XyEnterprise/Xyvision

Parents
  • Steve,

    Just an additional thought to my earlier anser...

    Could Xychange be made clever enough that if Xalan is found on the system, it would continue to use Xalan for the XSLTV1 stylesheets?
    Like that existing users will be able to sleep at night and do not have to worry about unexpected differences popping up in their transformation chains.

    I think it is very important that existing xpp transformations must continue to use the same XSLT engine as they have always done.

    In theory running an XSLT V1 stylesheet with a V2 engine should give you the same result, but we (Tine and me) have found at least 1 case where this is not the case.
    In this particular instance the V1 engine had been running without a problem for years. But wanting to speed things up, we forced xychange to use the V2 engine. That resulted in a fatal error and no output at all.
    (hey, I even found the files and stylesheets in question - can send them to you Steve or if you prefer that I open up a ticket that can be done as well - just let me know)

    The error that the V2 engine gave was:

    Pass 1, Transformation table: c:\Temp\xxx.xsl
    Static error at xsl:sort on line 2218 column 36 of xxx.xsl:
      XTSE0010: Within xsl:for-each, xsl:sort elements must come before other instructions
    Errors were reported during stylesheet compilation
    Error: Cannot create file C:/Temp/out.xml

    This was due to the following construct in the xslt:

     <xsl:for-each select="...">
    	<xsl:variable name="pridnbr">
    		<xsl:value-of select="@pridnbr"/>
    	</xsl:variable>
    ->	<xsl:sort order="ascending"/>
    

    This needed to be changed as follows in order to run on the V2 engine:

     <xsl:for-each select="...">
    ->	<xsl:sort order="ascending"/>
    	<xsl:variable name="pridnbr">
    		<xsl:value-of select="@pridnbr"/>
    	</xsl:variable>
    

    Not a big deal but still could be the cause of a complete production stop and some very angry users on the phone...

    I edited my earlier answer to reflect this.


    Bart

    PS: love your signature

  • Yes, it would be possible to test for the existence of "Xalan" and use it if we find it on the system.

  • In that case I have no objections at all.

    If you can just confirm that my list of what is needed to transport Xalan to another system is complete (and maybe as Chris suggested add that info to the installation/upgrade instructions)...

  • yes, we would do that. This is not for XPP 9.5, its for the future. The list of files would be provided at that time. It is also different depending on whether you are on Linux/Windows.

    But Chris is correct for at least the base names of the files on Windows

Reply Children
No Data