[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Closing Blueberry
- From: David Carlisle <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 19 Jul 2001 13:57:40 +0100
> So it seems. But why are people who will accept (a) allergic
> to (b)? Once you've opened up, you've opened up, and they
> are both character-level issues.
> Repeating: the NEL proposal does *not* change the grammar
> of XML: what it does is add NEL and LS (U+2028) to the
> list of things that are accepted externally and mapped
> to LF first thing by the parser.
Well since I'd spoke against it, I'll try to say why I would really
not like to see NEL introduced.
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.
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
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. However who's to say where U+2028 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? Of course, a parser isn't obliged to accept
anything other than utf-16/8 but users expect them to do more than that.
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.