Introducing TJSON, a stricter, typed form of JSON
Six things:<p>1) &quot;Lack of full precision 64-bit integers&quot; is bullshit.  Numeric precision is not specified by JSON.  If a parser can&#x27;t deal with 64-bit integer values, it&#x27;s a poor parser.<p>2) &quot;s: UTF-8 string&quot;  What does this mean?  JSON strings are strings of Unicode code points; JSON itself may be encoded as UTF-8, -16, or -32.  So does this mean &quot;encode the string as UTF-8, then represent as Unicode code points&quot;?  That makes no sense.<p>Does this mean &quot;encode the string as UTF-8 and output directly regardless of the encoding of the rest of the JSON output&quot;?  That makes no sense either.<p>So I&#x27;m guessing the author just conflated &quot;UTF-8&quot; with &quot;Unicode&quot;, which is concerning given that he is attempting to define an interchange protocol.<p>3) &quot;i: signed integer (base 10, 64-bit range)&quot;  What does this mean?  (-2^64,2^64)?  (-2^63,2^63)?  [-2^63,2^63)?<p>4) &quot;t: timestamp (Z-normalized)&quot;  What does that mean?  There are literally dozens of timestamp formats.  Does he mean full ISO 8601, restricted to UTC?<p>5) What is the point of TJSON anyway?  When you deserialize, you <i>still</i> have to check that the data is of the type you expect.  At best this saves a bit of parsing, since the deserializer can do that automatically.  Various JSON schema languages already exist, which give you this richer typechecking.<p>The only use case I can think of for this is exactly what the author mentions further down the article: canonicalization for content-aware hashing.  But this only works if the only types you care about fall into the small handful he thought of.  What about, say, IP addresses?  Case-insensitive strings (such as e-mail addresses)?<p>6) If we&#x27;re talking about canonicalization, TJSON does not say how to canonicalize decimal numbers.  I suppose this stems from the author&#x27;s mistaken belief that numbers in JSON are IEEE floats (they&#x27;re not, regardless of what common broken parsers do).<p>I hate to be so negative, but this really comes off as half-baked.<p>EDIT: Looking at the spec [1] it seems to address <i>some</i> of these, but still indicates a strong confusion between data <i>types</i> (Unicode, rational numeric) and data <i>representations</i> (UTF-8, IEEE double).<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;tjson&#x2F;tjson-spec&#x2F;blob&#x2F;master&#x2F;draft-tjson-spec.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tjson&#x2F;tjson-spec&#x2F;blob&#x2F;master&#x2F;draft-tjson-...</a>