Controlling EOL Convention for XSLT Output

[ronburk]

Is there any standard way to control the end-of-line convention (LF
versus CR/LF) for XSLT processor output?

The obvious logical point to control this would be in xslutput.
However, Kay says of its 'media-type' attribute "The specification
doesn't say what use is made of this information[...]", which sounds
pretty discouraging. I wonder how many XSLT processors running on *nix
actually emit CR/LF sequences when the output media-type is set to
"text/plain".

Note that this is *not* a question about what the octal code is for
carriage return, or how to manually insert a literal carriage return
into XSLT output.

 

[Joseph Kesselman]

Is there any standard way to control the end-of-line convention (LF
versus CR/LF) for XSLT processor output?

Remember, XML doesn't distinguish between these, and XSLT processes XML
data. This was deliberately left as an implementation detail so software
could use whichever convention made sense for the target processing
environment.

Some processors may support a PI, or command-line option, or extension
attribute, or some other hint to tell them which to use. Those which are
called via an API may be configurable at that level, by setting up the
output stream appropriately or setting a flag.

But there's no way to express this preference in pure XSLT itself.

 

[David Carlisle]

Is there any standard way to control the end-of-line convention (LF
versus CR/LF) for XSLT processor output?
No.

The obvious logical point to control this would be in xslutput.
However, Kay says of its 'media-type' attribute "The specification
doesn't say what use is made of this information[...]", which sounds
pretty discouraging. I wonder how many XSLT processors running on *nix
actually emit CR/LF sequences when the output media-type is set to
"text/plain".

Note that this is *not* a question about what the octal code is for
carriage return, or how to manually insert a literal carriage return
into XSLT output.

If you are using xml output method then it's fairly system dependent how
it gets serialised as the system can use any serialisation that would
parse the same way, so line endings are out of your control (unless
there is a processor-specific configuration)


but if you are using media type text/plain then presumably you are also
using thet text output method in which case I think it's reasonably safe
(but not guaranteed) that you just get whatever characters you have in
the result tree so use & # 1 3 ; & # 1 0 ; explictly to get crlf.

David

 

[ronburk]

Remember, XML doesn't distinguish between these, and XSLT processes XML

data.

That's not the issue. The issue is that XSLT does, after all, define
a 'media-type' attribute for output -- but renders it useless (that
is,
of less use than it could have been) by not requiring processors
to do anything with it.

The issue is nothing to do with what is happening with the EOL
during XSLT processing, it's only to do with xslutput, where
the standard goes all the way to specify how one specifies
a MIME type -- which is apparently of no portable use (since
the processor can ignore it).

 

[ronburk]

but if you are using media type text/plain then presumably you are also

using thet text output method in which case I think it's reasonably safe
(but not guaranteed) that you just get whatever characters you have in
the result tree so use & # 1 3 ; & # 1 0 ; explictly to get crlf.

In contrast, *I* think it's reasonably safe that text/plain will get
you
the EOL convention your XSLT processor (or its VM) was compiled with
(CR/LF for Windows processors, LF for Unix processors),
so you won't be able to get rid of that CR when you want
to run under Windows and produce text output suitable
for *nix. (I predicted I would get handed the character code for
CR and instructions for manually inserting, but was still unable
to prevent it. Damn your curse, Apollo!

Oh well, it all comes down to "tr -d '\r'" and an extra pass to
make things slower. Humph, but such is life.

 

[David Carlisle]

Oh well, it all comes down to "tr -d '\r'" and an extra pass to
make things slower. Humph, but such is life.

that is always an option, although as far as I can see saxon 8 (even on
windows) uses unix style endings always so if you want dos style ones
using an explict #13 as i suggested does the trick. But perhaps this
depends on exactly what jvm settings you have? I must admit I have
pretty much converged on saxon these days so I'm not sure what other
processors do.

david

 

[Joe Kesselman]

pretty much converged on saxon these days so I'm not sure what other
processors do.

I suspect many (most?) of those written in Java use the standard Java
mechanism for specifying newline, which would let you select either
option by setting the System Property "line.separator" before running
the transformation.