On Wed, Nov 13, 2013 at 5:48 PM, John Cowan
<cowan(_at_)mercury(_dot_)ccil(_dot_)org> wrote:
Joe Hildebrand (jhildebr) scripsit:
Although I hate UTF-32 with the heat of a several moderately-sized stars
and completely agree that UTF-8 is the one true path, I don't think we
can
completely remove UTF-32 from the bis draft. There may be existing
conformant JSON documents stored in UTF-32 that would be made unparseable
by this change.
Well, no, they would just be non-portable but legitimate extensions.
I like that approach a lot.
From an interop point of view it is FAR more likely that a reader supports
BSON than JSON-UTF32 and that is hardly likely to change.
Standards are read by people who implement encoders and decoders. What I
would like the spec to tell writers of encoders is that they MUST NOT use
UTF-32 encoding and call the result JSON. This is so that the spec can then
tell decoders that they have absolutely no need to support UTF-32 to comply
with the JSON spec.
Standards is about making choices that don't matter to the semantics or
performance of an operation. Taking an unnecessary option out is an
important and useful improvement.
This is incidentally why I was so peeved by the CBOR fiasco. First I am
told that my requirements don't matter, then the authors are throwing in
unnecessary complexity like definite length encodings because they can.
Any time a specification changes it is likely to cause some existing code
to stop being compliant. That is quite OK. The whole point of going through
this process was to reduce the probability that differences in
implementations would break interoperability.
UTF-32 is a difference in interoperability that adds no expressive value,
adds a great deal of complexity and damages performance. It has negligible
deployed base.
So kill it.
--
Website: http://hallambaker.com/