On Fri, Feb 25, 2011 at 3:09 PM, johne_ganz <john.engelhart@...> wrote: ... This is true statement, although the more practical question seems to be what...
I had the normalization question while writing json-stream in Ruby as well. I decided the parser shouldn't do Unicode normalization for the following reasons: ...
... True. It would seem, at least to me, that this is one of those nuanced points that either a) Has not been given the proper consideration by Unicode...
... This is my point. It happens both on the serialization side, but (at least in my opinion), it is much more likely to happen on the deserialization side. ...
Regarding the handling of numbers, the RFC doesn't appear to make any mention of native representations of numbers - in fact, it only specifies what...
... I think that limit is implied by the statement in the "Security considerations"; section that says that JSON is a subset of JavaScript, where numbers are...
... I agree in part. JSON parsers MUST NOT normalize their inputs, for the reasons given upthread. But JSON generators SHOULD generate normalization form C,...
... That's not quite right. JSON says nothing at all about number representations. All it knows is sequences of digits with the occasional decimal points. JSON...
... Normalization is non-trivial, and I doubt if any existing Unicode library imposes it on all strings at creation/modification time. Certainly ICU does not;...
... You are over-interpreting the standard. Of course applications can delete characters: sed -s 's/t//' deletes all t's from the input. And that's all...
... So you are now conceding that it's invalid JSON to send through unpaired surrogate code units, since they don't correspond to code points? We discussed...
... Yes. ... Ok. But in this case, would JSON specification itself help a lot? I understand that this is problematic, in that different platforms can choose...
Hello all, Huge speed optimizations in fastJSON v1.4 now officially the fastest JSON on the .net platform. http://www.codeproject.com/KB/IP/fastJSON.aspx...
Jansson 2.0 is finally out. This is a new major release that is (slightly) backwards incompatible with the older versions. Changes since v1.3 ... * Backwards...
... It is my opinion that the answer is "Yes". The standard must address some of the issues introduced by the use of Unicode (see below). Then there is the...
... The Foundation framework (specifically the NSString class) on Mac OS X and iPhone / iPad does. Not sure if 90+ million iPhones count for much, though. In...
Would it be too much to specify that key names are to be ASCII top-bit-unset strings? i.e. in the definition of an object, designate that the "string" there is...
Better question: How does the ECMA/javascript spec limit variable names? This seems to be the same question, in practical terms. Dave. ... [Non-text portions...
To save people looking it up: ECMA-262, section 7.6: Two IdentifierName that are canonically equivalent according to the Unicode standard are not equal unless...
... I am aware of that :) It occurs to me that since the intention is that JSON text deserializes into an instanced object, which will in some cases be a ...
... Indeed they would, which is precisely why {foo: "bar"} is not conformant JSON any more than {if: "bar"} would be, although the first is conformant ...
... I don't think so. In particular, it is often helpful to allow keys named "$" or "#foo" or such. In any case, the normalization rule for JavaScript ...
... Actually, it doesn't mean anything, because the RFC only says that the keys of an object SHOULD (not MUST) be unique. In practice, people probably parse...
... Yup, it got here in Normalization Form C, using U+00C4 in both cases. But that's email for you, and perhaps that's Apple for you too. I'd stick with...
