OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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