On Wed, Nov 13, 2013 at 5:48 PM, John Cowan <cowan@xxxxxxxxxxxxxxxx> wrote:
Joe Hildebrand (jhildebr) scripsit:
Well, no, they would just be non-portable but legitimate extensions.
> 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.
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/