[ https://issues.apache.org/jira/browse/NIFI-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656209#comment-17656209 ]
Daniel Stieglitz edited comment on NIFI-10582 at 1/10/23 5:25 PM: ------------------------------------------------------------------ [~gkonar] I believe I see what the issue here is but I am not an XSLT guru to solve the exact problem. I believe you are experiencing the issue seen in the following Stackoverflow post [Why is xsl:value-of behaving completely different depending on the xsl:stylesheet version|https://stackoverflow.com/questions/73497698/why-is-xslvalue-of-behaving-completely-different-depending-on-the-xslstyleshee]. Please note under the hood TransformXml is using Saxon HE 10.6 which conforms with the W3C Recommendations for XSLT 3.0, XPath 3.1, and XQuery 3.1 while xsltproc is an XSLT 1.0 processor as stated [here|https://stackoverflow.com/questions/25061696/xsltproc-doesnt-recognize-xslt-2-0]. Hence you are seeing a difference in how xsl:value-of is being interpreted on line 182 of your XSLT: {code:java} <xsl:value-of select="text()" /> {code} Please note the the new line is being inserted for both files when there is no text for the node but rather a sequence of empty spaces. In 14_R01.svg lines 49-50 {code:java} <text id="Text21" font-family="Arial" font-size="14" x="255" y="82" xml:space="preserve" style="dominant-baseline: auto;" text-anchor="start" fill="rgb(32,32,32)"> </text> {code} In 21_R01.svg (lines 43-44) {code:java} <text id="Text18" font-family="Arial" font-size="14" x="171" y="422" xml:space="preserve" style="dominant-baseline: auto;" text-anchor="start" fill="rgb(32,32,32)"> </text> {code} Based on this [documentation|https://xsltdev.com/xslt/xsl-value-of/] there is a difference how XSLT 1.0 and 2.0 (and I believe the same goes for 3.0) if the select expression evaluates to a sequence containing more than one item. Without a separator specified (which svgTest.xsl does not specify) in XSLT 1.0 only the first item is considered but in XSLT 2.0 (and 3.0) the sequence of items separated by the default separator a space is used. When using xsltproc which uses XSLT 1.0, there is no new line since only the first item a blank space is chosen, while when using TransformXml a "new line" is inserted as it is the sequence of spaces found in the node separated by single spaces. So in a sense it is part of that data line. It looks like you need some sort of trim function to get rid of the sequence of spaces when capturing the text. As for a possible backwards compatible mode for XSLT 1.0 which seemed possible based on the first article I quoted, it seems there is none for XSLT 3.0 based on the following [support ticket|https://saxonica.plan.io/issues/4266]. Hence I believe what you have observed is not a bug but rather a consequence of using XSLT 3.0. Please let me know if you concur with this conclusion. was (Author: JIRAUSER294662): [~gkonar] I believe I see what the issue here is but I am not an XSLT guru to solve the exact problem. I believe you are experiencing the issue seen in the following Stackoverflow post [Why is xsl:value-of behaving completely different depending on the xsl:stylesheet version|https://stackoverflow.com/questions/73497698/why-is-xslvalue-of-behaving-completely-different-depending-on-the-xslstyleshee]. Please note under the hood TransformXml is using Saxon HE 10.6 which conforms with the W3C Recommendations for XSLT 3.0, XPath 3.1, and XQuery 3.1 while xsltproc is an XSLT 1.0 processor as stated [here|https://stackoverflow.com/questions/25061696/xsltproc-doesnt-recognize-xslt-2-0]. Hence you are seeing a difference in how xsl:value-of is being interpreted on line 182 of your XSLT: {code:java} <xsl:value-of select="text()" /> {code} Please note the the new line is being inserted for both files when there is no text for the node but rather a sequence of empty spaces. In 14_R01.svg lines 49-50 {code:java} <text id="Text21" font-family="Arial" font-size="14" x="255" y="82" xml:space="preserve" style="dominant-baseline: auto;" text-anchor="start" fill="rgb(32,32,32)"> </text> {code} In 21_R01.svg (lines 43-44) {code:java} <text id="Text18" font-family="Arial" font-size="14" x="171" y="422" xml:space="preserve" style="dominant-baseline: auto;" text-anchor="start" fill="rgb(32,32,32)"> </text> {code} Based on this [documentation|https://xsltdev.com/xslt/xsl-value-of/] there is a difference how XSLT 1.0 and 2.0 (and I believe the same goes for 3.0) if the select expression evaluates to a sequence containing more than one item. Without a separator specified (which svgTest.xsl does not specify) in XSLT 1.0 only the first item is considered but in XSLT 2.0 (and 3.0) the sequence of items separated by the default separator a space is used. When using xsltproc which uses XSLT 1.0 there is no new line since only the first item a blank space is chosen while when using TransformXml a "new line" is inserted as it is the sequence of spaces found in the node separated by single spaces. So in a sense it is part of that data line. It looks like you need some sort of trim function to get rid of the sequence of spaces when capturing the text. As for a possible backwards compatible mode for XSLT 1.0 which seemed possible based on the first article I quoted, it seems there is none for XSLT 3.0 based on the following [support ticket|https://saxonica.plan.io/issues/4266]. Hence I believe what you have observed is not a bug but rather a consequence of using XSLT 3.0. Please let me know if you concur with this conclusion. > <xsl:strip-space> XSLT element does not work in NiFi 1.15.3 > ----------------------------------------------------------- > > Key: NIFI-10582 > URL: https://issues.apache.org/jira/browse/NIFI-10582 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework > Affects Versions: 1.15.3 > Environment: Windows 10 Pro, 21H2, 64-bit O/S, 64GB RAM > Apache NiFi 1.15.3 > openjdk version "11" 2018-09-25 > OpenJDK Runtime Environment 18.9 (build 11+28) > OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode) > Reporter: Greg Konar > Priority: Major > Attachments: 14_R01.csv, 14_R01.csv_err, 14_R01.svg, 21_R01.csv, > 21_R01.csv_err, 21_R01.svg, Reproduce_NiFi_Error.xml, svgTest.xsl > > > I was using NiFi to convert SVG files to pipe delimited format so I can load > and convert them to a proprietary XML structure required by our application. > One client sent us files that contained rogue newline characters which caused > nearly 25% of the files to fail to load. Using *<xsl:strip-space>* in my > XSLT file, I was able to manually "repair" the files. > When the _*TransformXML*_ processor was pointed to my svgTest.xsl XSLT file, > the files still failed to load. > To prove the file was good, I created a bash shell script which applied the > XML transformation to my SVG files, then I injected the delimited files at a > later point in my flow. ALL FILES LOADED. > Please find my _*svgTest.xsl*_ file attached. > Please fix this bug in NiFi and let me know which version contains the fix as > I am our company's "NiFi Champion". > If you have any questions or need additional information, please let me know. > Thank you in advance. -- This message was sent by Atlassian Jira (v8.20.10#820010)