#718535 libxslt1.1: behavior of indent xsl:output attribute should be documented

Package:
libxslt1.1
Source:
libxslt
Description:
XSLT 1.0 processing library - runtime library
Submitter:
Vincent Lefevre
Date:
2021-07-06 09:39:03 UTC
Severity:
normal
Tags:
#718535#5
Date:
2013-08-02 00:19:16 UTC
From:
To:
When indent="no" is used, some newline characters are missing,
in particular at the end of the file. This is a regression. And
using indent="yes" is not an acceptable workaround as it is not
safe, as said by the XSLT spec:

  NOTE: It is usually not safe to use indent="yes" with document types
  that include element types with mixed content.

For instance, for the following "copy.xsl" file:

<?xml version="1.0" encoding="utf-8"?>
<!-- Comment 1 -->
<!-- Comment 2 -->

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method="xml" indent="no"/>

<xsl:template match="node()|@*">
  <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
  </xsl:copy>
</xsl:template>

</xsl:stylesheet>

I get with bash:

vinc17@xvii:~$ xsltproc copy.xsl copy.xsl
<?xml version="1.0"?>
<!-- Comment 1 --><!-- Comment 2 --><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:output method="xml" indent="no"/>

<xsl:template match="node()|@*">
  <xsl:copy>
    <xsl:apply-templates select="node()|@*"/>
  </xsl:copy>
</xsl:template>

</xsl:stylesheet>vinc17@xvii:~$

The newline characters before and after the root element should be
preserved, possibly squashed. And when a DOCTYPE line is generated,
there should be a newline character after it. AFAIK the XSLT spec
says nothing about these newlines (and more generally spaces) since
they have no meaning in the XML tree. So, let's see the pros and cons.

Pros: readability; better usability with line-based tools, such as
"diff" (to compare generated output), "svn blame" and so on.

Cons: very little wasted space. But this should be not be significant
in practice, compared to the whole document.

Also, if the user has added newlines in the source, this may be for a
good reason.

More importantly, the final newline character is missing, which can
break some tools. Let's recall that for POSIX, a text file must end
with a newline character, and POSIX tools are not required to work
without it.

#718535#10
Date:
2013-08-04 16:12:53 UTC
From:
To:
libxslt does exactly what you want if you don't provide an indent attribute at all.

indent="yes": Let libxslt add whitespace.
indent="no": Never add whitespace.
no indent attribute: Add newline after top-level nodes.

Nick

#718535#15
Date:
2013-08-05 01:33:39 UTC
From:
To:
This is rather confusing as the XSLT spec

http://www.w3.org/TR/xslt

says: "If the indent attribute has the value yes, then the xml output
method may output whitespace in addition to the whitespace in the
result tree (possibly based on whitespace stripped from either the
source document or the stylesheet) in order to indent the result
nicely; if the indent attribute has the value no, it should not output
any additional whitespace. The default value is no."
                           ^^^^^^^^^^^^^^^^^^^^^^^

So, though the behavior is not really disallowed by the spec, I would
have expected indent="no" to give the same result as no indent
attribute. Unfortunately this is not documented, at least in the
man pages, and this change hasn't been announced either.

#718535#20
Date:
2013-08-05 09:08:16 UTC
From:
To:
I think it's a good compromise. The change is related to this bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=652766

I agree that this should be documented somewhere. If this issue is
important to you, I'd suggest you file a bug report at
bugzilla.gnome.org or take it to the libxslt mailing list
(xslt@gnome.org) where you're more likely to get answers.

Nick

#718535#25
Date:
2013-08-05 11:06:50 UTC
From:
To:
Control: tags -1 upstream
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=705489
Control: retitle -1 libxslt1.1: behavior of indent xsl:output attribute should be documented

I think the behavior is OK for me. So the problem of the documentation
remains, at least to make sure that another incompatible change isn't
done in the future (possible except for a good reason, such as new
recommendations from the W3C).