Re: ByteString in Web IDL

On Jul 10, 2013, at 15:32 , Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Jul 10, 2013 at 6:21 PM, Norbert Lindenberg
> <ecmascript@lindenbergsoftware.com> wrote:
>> Using ByteString effectively imposes ISO 8859-1. That seems to be required for legacy reasons in XMLHttpRequest, but it would generally be the wrong choice for any new API.
> 
> It's absolutely the right choice (though calling it iso-8859-1 is
> confusing as that means windows-1252 in browsers) as that preserves
> the value space.

I'm referring to the actual ISO 8859-1, not the impostor.

"Preserves the value space" is only half-true because the setters accepting ByteString reject all code points above U+00FF in the ECMAScript strings that are the real input.

> Exposing the bytes works too of course, but given
> most byte sequences are "ASCII-compatible" that would be a bad API.

What do you mean by "most byte sequences are ASCII-compatible", and why would that make actual bytes a bad API?

An API that provides access to bytes representing characters in undefined character encodings should help applications in determining the character encoding and converting to/from well-defined character sequences. I've presented a number of options that I believe would all be more useful than byte sequences masquerading as character sequences.

Anyway, we don't need to design a new API here. Boris and Jonas have pointed out that the XMLHttpRequest API has to behave the way it does because it's a legacy API, and I accept that. What I'm asking for is that this legacy doesn't prejudice new APIs, that ByteString is removed from Web IDL, and that the legacy behavior is described entirely within the XMLHttpRequest spec.

Thanks,
Norbert

Received on Tuesday, 16 July 2013 06:13:12 UTC