Line breaks in text mode for XSLT

[David Blickstein]

I'm finding it difficult to determine when/where XSLT generates line breaks
when generating a text file <xslutput method="text"
media-type="text/plain"/>

And... I'm getting thoroughly different results from whatever XSLT processor
comes with Altova XMLSpy than I'm getting from Xalan.

Can anyone give me a small tutorial on this topic?

Thanks,

Dave Blickstein

 

[David Carlisle]

I'm finding it difficult to determine when/where XSLT generates line breaks
when generating a text file <xslutput method="text"
media-type="text/plain"/

It never breaks lines at all, line ends will just be inserted at places
that you insert them explitly in your code (or copy them from teh
source)

And... I'm getting thoroughly different results from whatever XSLT processor
comes with Altova XMLSpy than I'm getting from Xalan.

Possibly xmlspy is using the msxml parser which will throw away any
white space nodes on input (which is a documented non-conformance)
so if you are copying nodes from the source to the result it's quite
likely that you lose white space if msxml is being used.

Can anyone give me a small tutorial on this topic?

Thanks,

Dave Blickstein

David

 

[David Blickstein]

Possibly xmlspy is using the
msxml parser which will throw away any

white space nodes on input (which is a documented non-conformance)
so if you are copying nodes from the source to the result it's quite
likely that you lose white space if msxml is being used.

Thank you SO MUCH for taking the time to reply.

You were right. When I added an xsl:strip-space tag, the results were
correct with both XMLSpy and Xalan.

I'll confessed I'm at a loss to explain WHY that corrected it because
essentially ALL the content in this section is drawn from attribute values
(which I know don't contain any newline characters) rather than element
content but... I'm just happy it worked.

Thanks again,

Dave Blickstein

 

[David Carlisle]

ALL the content in this section is drawn from attribute values

I guess you just proved that statement false

Most likey you have

<x>
<y foo="1"/>
<y foo="2"/>
<y foo="3"/>
</x>


And have a template
<xsl:template match="y">
<xsl:value-of select="@foo"/>
</xsl:template>


but the reason that the template for y gets called is that the default
template for <x> is doing <xsl:apply-templates/> which is
<xsl:apply-templates select="node()"/>
so by default applies templates to (and copies) the white space nodes
used to indent the input.

David

 

[David Blickstein]

That explains it. Interestingly, in this particular stylesheet there are no
apply-template tags so there was nothing to "look for" along those lines,
but obviously the default actions kicked in.

Thank you so much again. It used to be a total pain for me to get the
stylesheets to do what I wanted them to do, since adding the strip-space
tag, everything now happens as I expect and I'm making rapid progress.

Thanks again,

db

 

[Peter Flynn]

That explains it. Interestingly, in this particular stylesheet there are
no apply-template tags so there was nothing to "look for" along those
lines, but obviously the default actions kicked in.

Thank you so much again. It used to be a total pain for me to get the
stylesheets to do what I wanted them to do, since adding the strip-space
tag, everything now happens as I expect and I'm making rapid progress.

If your application uses mixed content, be careful that strip-space doesn't
bite you in the butt: there is an unpleasant side-effect that the space
between two adjacent elements will be removed even in mixed content, even
using a Schema or DTD where the XSLT application ought to know better, eg

<para>Remove <part no="abc123">the nut</part> <emph>anti-clockwise</emph>...

will give you "Remove the nutanti-clockwise". This isn't a bug: it's just
rather sloppy design -- so strip-space really does mean what it says,
and has been implemented for use in "data" XML rather than "document"
applications which use mixed content models where white-space nodes should
be normalized to a single space token, not normalized out of existence.

///Peter