xsl-list
[Top] [All Lists]

[xsl] Hidden implementation-defined behaviour

2007-07-05 00:23:04
I have just discovered an interesting difference in behaviour between saxon and gexslt with respect to unparsed-text() that appears to be undefined by the spec.

Gexslt is ready the file as a text file (which seems reasonable given the name of the function, but not mandated by the spec, which just talks about the contents of the resource), and accordingly CRLF combinations (this is a windows file on windows) are being read as a single newline, so now CRs are present in resulting string.

On the otherhand Saxon retains the CRs in the resulting string (I noticed the difference as I was calling string-length).

As far as I can see, both behaviours are legitimate, so it is something to beware of (calling translate(unparsed-text($uri, "
", "")) gives portable behaviour).

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.co.uk


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>