Re: Closing Blueberry
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format