Re: [xslt] Controlling EOL Convention with xsltproc

[Ron Burk <ronburk hightechinfo com>]

> Or, of course, simply using "wb" instead of "w" as argument to fopen();

On all but pre-opened streams (stdout), that's fine.

> I don't think it's ever wrong for xsltproc to do that *for XML (or HTML)
> output*.

Not sure what you're thinking there -- you can't
really suddenly change the default behavior of
the Windows xsltproc to use Unix line endings without
upsetting users, I think. Also, you don't want xsltproc's
stdout to inexplicably use a different EOL convention
than output produced via (e.g.) xsl:document, so again any
meaningful tinkering can't be isolated to just the
xsltproc shell, I guess, nor can it be the same default
behavior for both Windows and *nix processors.


> For text/plain output, for example, the line endings may be relevant,
> and whatever line endings xsltproc chooses to use could be "wrong" in
> some context.

Am I mistaken in reading RFC 2046 4.1.1 to mean there's really
only one legal line ending for "text/plain"?

   The canonical form of any MIME "text" subtype MUST always represent a
   line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
   MIME "text" MUST represent a line break.  Use of CR and LF outside of
   line break sequences is also forbidden.

> Choosing to use the "platform default", as is done by
> outputting in non-binary mode using a C runtime, is the most sensible
> choice IMHO

Sure, if we're talking about the default case where you
haven't specified precisely what you want via a 'media-type'
attribute on an xsl:output.

> For an XML file itself it should not matter, but
> for the output of a transform it might.

Yes, when producing LaTeX, it matters mightily that
you don't hand it CR/LF when it expects LF.

Found an old xsltproc on a Linux system and ran
a test of an xsl:document with a 'media-type' of
"text/plain". Output appeared have EOLs of LF,
which violates RFC 2046, but not the XSLT standard,
if my understanding is correct.

Anyway, the net answer is the same. No portable way to
produce LF EOLs on Windows; no non-portable way to do it
with xsltproc. XSLT lets you specify a MIME type, but
that's just syntactic noise; probably no processors are
producing conforming output based on that directive.