[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Closing Blueberry
- From: John Cowan <email@example.com>
- To: David Carlisle <firstname.lastname@example.org>
- Date: Thu, 19 Jul 2001 12:02:35 -0400
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
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
> However who's to say where U+2028
That is LS, by the way; NEL is U+0085.
> 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 <email@example.com>
no more / no less || http://www.reutershealth.com
to do / all things || http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein