Cart
[Home] [By Thread] [By Date] [Recent Entries]
David Carlisle wrote: > Firstly giving up all the feature that all XML syntax characters are in > the ASCII range thus easily (human) readable on the vast majority of > systems should not be done without overwhelmingly strong reasons. Oh? See what happens when you print an XML file using LF-only to a Windows printer. Lotsa very black glyphs on the top line. Line-end variations are one of those irritating things when moving plain text (not just XML) from one system to another. > Adding NEL to XML white space as opposed to just fixing (or changing, > according to your point of view) the ebcdic mapping tables has no > advantages to anybody as far as I can see, whether or not they use > ebcdic. For the Nth time, I am *not* proposing adding NEL/LS to XML white space! I am proposing changing what XML understands as a low-level line end. This is quite different. > Currently the XML declaration is in effect all ascii and so this means > in practice that the vast majority of encoding declartions can be read: > the system can make a good enough guess of the encoding to get as far as > reading the encoding declaration. EBCDIC encoding of XML (using CR or LF or CRLF, not NEL) is already supported. > However who's to say where U+2028 That is LS, by the way; NEL is U+0085. > gets > mapped to? so when faced with some arbitrary byte sequence at the start > of the file, how far do you go before deciding that this isn't NEL in > some wacky encoding? EBCDIC files begin with the EBCDIC for "<?xml". No NEL is involved. -- There is / one art || John Cowan <jcowan@r...> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
|
