XSLT in Author

[Bilbo Duntze]

Hi,

I have an XML file encoded in ISO8859-1 using a lot of entities that are defined in an DTD and have some trouble when invoking an XSLT-Transformation in a framework via the XSLTOperation class.

My XSLT reads another XML-file (encoded in UTF-8) via the XPath document()-function and compares strings from this source with strings from the XML that is transformed. When I define a Transformation scenario, everything works fine. If I compare for instance the string "Ümlaut" from the ISO-encoded XML source with the string "Ümlaut" from the UTF-8 encoded reference XML, matches() returns 'true'. The first string is internally parsed as a unicode-string, which is the behavior I would expect from Saxon. This also works, when I define a function in my framework starting the transformation scenario via the "ExecuteTransformationScenariosOperation" class

But, when I invoke the script via Author mode's "XSLTOperation", the first sting is internally parsed as "Ümlaut"(!) and when using the match()-function to compare it to "Ümlaut", the result is 'false'.
It doesn't matter if I copy the script directly in the XSLTOperation's 'script' attribute, or if I insert just a link to the script that is stored in my framework directory.

It seems this behavior occured after moving to oxygen 25.1, but I can't test it.
I attached a very simple test file and a test scenario with an XSLT and predefined functions for author mode, reproducing the problem.

Any ideas on this?
Thanks,
Bilbo

[johnwood]

To troubleshoot this issue, you could try a few things:

1. Check the encoding settings in the XSLTOperation class to ensure that the input XML file is being read correctly. Make sure that the encoding settings match the actual encoding of the file.
2. Check the DTD file to make sure that the entities are defined correctly. If the entities are defined incorrectly or not at all, this could cause the issues you are seeing.
3. Try running the transformation with a different XSLT processor, such as Saxon, to see if the issue persists. This could help you narrow down whether the problem is with the input XML file or with the XSLTOperation class.

[Radu]

Hi Bilbo,

Right, in Oxygen 25.0 we took the decision not to expand entity references in the XML content on which the XSLTOperation is applied:

https://www.oxygenxml.com/doc/versions/ ... yoperation

Entities are treated as plain text and not expanded.

We do this by escaping the entity reference, so if the original entity ref is "&ref;" we escape it to "&ref;" before loading the XML in the XSLT operation.
We took this decision because the XSLTOperation would usually process the XML somehow and then insert it back and when inserted we wanted the entity reference to remain escaped and not to have it expand to its referenced content.
I'm afraid we do not have a setting to disable this change in behavior. If you agree I can try to add a setting for disabling this behavior in our next Oxygen 26 release (Autumn this year).

Regards,
Radu

[Radu]

Hi,
We made a minor Oxygen 25.1 bug fix release which adds a parameter to control this behavior:
https://www.oxygenxml.com/build_history.html#2023070306

Author: Added a new parameter named escapeEntityRefs to the TransformOperation Author operation to control if entity references are escaped as plain text in the processed content.

Regards,
Radu