Re: Closing Blueberry

[John Cowan <jcowan@reutershealth.com>]

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@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein