XalanJ2
  1. XalanJ2
  2. XALANJ-656

<xsl:copy> introduces inappropriate line-end characters processing comments

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0
    • Fix Version/s: None
    • Component/s: Xalan
    • Labels:
      None
    • Environment:
      Operating System: MacOS 9
      Platform: Macintosh

      Description

      I was trying to write a template that would correctly reproduce the script
      body of a JavaScript (which is typically 'masked' by a comment). My initial
      attempt was:

      <xsl:template match="script/comment()">
      <xsl:copy/>
      </xsl:template>

      which worked, except that the copied script contained newline (ASCII 10)
      in place of the carriage-return (ASCII 13) characters in the original. Note
      that this is on a Macintosh, where line-endings are terminated by CR
      rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
      guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
      rather than the appropriate platform-specific line terminators.

      A workaround is to use:

      <xsl:template match="script/comment()">
      <xsl:comment><xsl:value-of select="."/></xsl:comment>
      </xsl:template>

        Issue Links

          Activity

          Hide
          david_marston added a comment -

          One would think that a JDK for the Mac would produce the new-line sequence
          that the Mac wants. In a discussion with a couple of the people very familiar
          with Xalan code, they asserted that Xalan relies on the JDK to handle new-lines
          and be aware of its platform. Can any Mac specialists comment further?

          Show
          david_marston added a comment - One would think that a JDK for the Mac would produce the new-line sequence that the Mac wants. In a discussion with a couple of the people very familiar with Xalan code, they asserted that Xalan relies on the JDK to handle new-lines and be aware of its platform. Can any Mac specialists comment further?
          Hide
          Ross Gardler added a comment -

          It looks like this Xalan issue is the root cause of this problem.

          Show
          Ross Gardler added a comment - It looks like this Xalan issue is the root cause of this problem.
          Hide
          Ross Gardler added a comment -

          It looks like this xalan issue us our root cause.

          Show
          Ross Gardler added a comment - It looks like this xalan issue us our root cause.
          Hide
          Ross Gardler added a comment -

          Sorry, I incorrectly linked the first time, then didn't give a very good comment the second time (stupid me didn't think about the comment being applied to the Xalan issue as well as the Forrest issue). So here's a decent comment for you:

          FOR-492 is an issue that describes the same symptoms as those described in this issue. It is manifesting itself in a more critical way though. We have a tool called the Forrestbot which automatically generates and deploys Forrest generated sites. One of the mechanisms for deploying the site is to an SVN server.

          Unfortunately, this fails because of the inconsitent line endings this issue creates.

          Show
          Ross Gardler added a comment - Sorry, I incorrectly linked the first time, then didn't give a very good comment the second time (stupid me didn't think about the comment being applied to the Xalan issue as well as the Forrest issue). So here's a decent comment for you: FOR-492 is an issue that describes the same symptoms as those described in this issue. It is manifesting itself in a more critical way though. We have a tool called the Forrestbot which automatically generates and deploys Forrest generated sites. One of the mechanisms for deploying the site is to an SVN server. Unfortunately, this fails because of the inconsitent line endings this issue creates.
          Hide
          David Crossley added a comment -

          The original report for this Xalan issue said that the operating system was Mac OS 9. As Ross reported, we also see the issue at Apache Forrest and none of our committers are using Mac OS 9.

          It is usually me updating our website (on Linux or Max OS X). Then occasionally a Windows-based committer does. Then we see these line-ending issues within the xml comments in the transformed docs. We use XalanJ 2.7.0

          Show
          David Crossley added a comment - The original report for this Xalan issue said that the operating system was Mac OS 9. As Ross reported, we also see the issue at Apache Forrest and none of our committers are using Mac OS 9. It is usually me updating our website (on Linux or Max OS X). Then occasionally a Windows-based committer does. Then we see these line-ending issues within the xml comments in the transformed docs. We use XalanJ 2.7.0
          Hide
          Brian Minchau added a comment -

          I just ran this stylesheet with Xalan-J 2.7.0:
          ---------------------------------------------------------
          <xsl:stylesheet
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
          version="1.0"
          xmlns:xalan="http://xml.apache.org/xalan">

          <xsl:output method="xml" indent="yes" xalan:line-separator="EOL" />

          <xsl:template match="/"><out></out><xsl:comment>Newline in a comment:
          Next line
          Eight</xsl:comment><out2>Newline in text node:
          Next line in text</out2></xsl:template></xsl:stylesheet>
          ---------------------------------------------------------

          Note that it uses the xalan specific line-separator property introduced in version 2.7. It sets the end of line separator to the unrealistic, but very visible value of "EOL". Obviously a better attribute value would be " "

          The output from the stylesheet above is:
          --------------------------------------------------------
          <?xml version="1.0" encoding="UTF-8"?>EOL<out xmlns:xalan="http://xml.apache.org/xalan"/>EOL<!--Newline in a comment:
          Next line
          Eight-->EOL<out2 xmlns:xalan="http://xml.apache.org/xalan">Newline in text node:EOLNext line in text</out2>EOL
          --------------------------------------------------------

          So there is a way to specify the end of line characters, and it works within a text node, you can see the "EOL" in the middle of the output text. However, I think the issue here is that an end of line sequence in a comment is left as-is. Is that it? Is one wishing the output to be this for the comment:
          <!-Newline in a comment:EOLNext lineEOLEight->

          Even so, is this allowed within the XSLT 1.0 specification on how comments are processed?

          Show
          Brian Minchau added a comment - I just ran this stylesheet with Xalan-J 2.7.0: --------------------------------------------------------- <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:xalan="http://xml.apache.org/xalan"> <xsl:output method="xml" indent="yes" xalan:line-separator="EOL" /> <xsl:template match="/"><out></out><xsl:comment>Newline in a comment: Next line Eight</xsl:comment><out2>Newline in text node: Next line in text</out2></xsl:template></xsl:stylesheet> --------------------------------------------------------- Note that it uses the xalan specific line-separator property introduced in version 2.7. It sets the end of line separator to the unrealistic, but very visible value of "EOL". Obviously a better attribute value would be " " The output from the stylesheet above is: -------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?>EOL<out xmlns:xalan="http://xml.apache.org/xalan"/>EOL<!--Newline in a comment: Next line Eight-->EOL<out2 xmlns:xalan="http://xml.apache.org/xalan">Newline in text node:EOLNext line in text</out2>EOL -------------------------------------------------------- So there is a way to specify the end of line characters, and it works within a text node, you can see the "EOL" in the middle of the output text. However, I think the issue here is that an end of line sequence in a comment is left as-is. Is that it? Is one wishing the output to be this for the comment: <!- Newline in a comment:EOLNext lineEOLEight -> Even so, is this allowed within the XSLT 1.0 specification on how comments are processed?
          Hide
          Gavin added a comment -

          Hi Guys,

          Just bumping this issue. This line endings problem is still causing problems within Forrest and now others that rely on Forrest I believe are beginning to speak up. Does anyone have any ideas on the way forward here, can I assist in any way, even if only testing on my Windows system.?

          Show
          Gavin added a comment - Hi Guys, Just bumping this issue. This line endings problem is still causing problems within Forrest and now others that rely on Forrest I believe are beginning to speak up. Does anyone have any ideas on the way forward here, can I assist in any way, even if only testing on my Windows system.?
          Hide
          Gavin added a comment -

          Forgot to add, Issue http://issues.apache.org/jira/browse/FOR-492 has been active again and provides more info.

          Show
          Gavin added a comment - Forgot to add, Issue http://issues.apache.org/jira/browse/FOR-492 has been active again and provides more info.
          Hide
          Brian Minchau added a comment -

          Hi Gavin,
          this issue was opened against the 2.2.0 release long ago. What release are you using? 2.7?

          If the bug gets fixed, is development code change good enough, or do you want it in a real future release, such as 2.7.1 (which doesn't exist yet).

          I've mentioned earlier in this issue that there is a xalan specific line-separator property on xsl:output, is that not a sufficient work around?

          Regards,

          • Brian
          Show
          Brian Minchau added a comment - Hi Gavin, this issue was opened against the 2.2.0 release long ago. What release are you using? 2.7? If the bug gets fixed, is development code change good enough, or do you want it in a real future release, such as 2.7.1 (which doesn't exist yet). I've mentioned earlier in this issue that there is a xalan specific line-separator property on xsl:output, is that not a sufficient work around? Regards, Brian
          Hide
          David Crossley added a comment -

          Thanks Brian, from time-to-time i have reviewed your previous comments and tried to see how it can help Forrest. Then i needed to encourage our people to clarify FOR-492 (done now).

          Yes we use Xalan-2.7.0 release currently (see above). The Forrest project has agreed in the past that it is quite fine for us to make own our package of supporting products at a known svn revision. Is that what you mean by "is development code change good enough"?

          We want to avoid Xalan-specific properties so that our users can switch to Saxon.

          We have pipelines of many separate xml transformations. Cocoon ignores xsl:output from transformer stylesheets.
          Re: xsl:output
          http://marc.theaimsgroup.com/?t=105940320700001

          Show
          David Crossley added a comment - Thanks Brian, from time-to-time i have reviewed your previous comments and tried to see how it can help Forrest. Then i needed to encourage our people to clarify FOR-492 (done now). Yes we use Xalan-2.7.0 release currently (see above). The Forrest project has agreed in the past that it is quite fine for us to make own our package of supporting products at a known svn revision. Is that what you mean by "is development code change good enough"? We want to avoid Xalan-specific properties so that our users can switch to Saxon. We have pipelines of many separate xml transformations. Cocoon ignores xsl:output from transformer stylesheets. Re: xsl:output http://marc.theaimsgroup.com/?t=105940320700001

            People

            • Assignee:
              Unassigned
              Reporter:
              Angus McIntyre
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development