RE: Hidden implementation-defined behaviour

Actually the WG discussed whether unparsed-text() should normalize line
endings and decided that it should not (IIRC my view was that it should, but
others felt that "unparsed" should mean what it says.)

It's true that a wise application writer will allow for variations in line
endings, because it's hard to predict how the file will have been written;
but there's no license in the spec, in my view, for the XSLT processor to
modify the contents of the resource other than by decoding the octets into
characters.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: Colin Adams [mailto:colinpauladams@xxxxxxxxxxx] 
> Sent: 05 July 2007 08:23
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  Hidden implementation-defined behaviour
> 
> 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