A: TJSON is intended to supplement binary message formats, not replace them. It provides a syntax which should be able to express most of the same types as binary formats in both a human readable/writable and cryptographically authenticatable manner. It should also hopefully support lossless bidirectional transcoding to and from binary formats.
This should allow systems to represent data in a binary format or SQL database natively, but use TJSON to facilitate API exploration, discussion about data encoded in the binary format expressed as TJSON, and potentially clients that work on TJSON natively because supporting the binary format is deemed too onerous.
Schema languages are great, however they have not proven to be popular among the users of JSON, and the majority of JSON is consumed in a schema-free manner. TJSON allows those consuming JSON in a schema-free manner to get some of the benefits of schema languages without having to fully adopt one.
A: TJSON imposes a number of strictness requirements which are not present in JSON itself. For example, UTF-8 is the only valid TJSON string encoding and repeated keys in objects are disallowed. Additionally, the TJSON specification also comes with a comprehensive set of test cases to ensure conforming parsers exhibit the same behavior when parsing TJSON documents.
A: Language support for TJSON is scant right now, but we're working on it. Feel free to make a TJSON implementation for your language, and if you'd like, request to host it under the TJSON GitHub organization.
In the meantime you can consume TJSON documents by stripping off the tags and doing manual postprocessing. Chances are if you're working with rich types in JSON documents, you're probably doing this postprocessing by hand already.
A: TJSON is intended to support format-independent cryptographic authentication using the objecthash content hash algorithm. This algorithm produces digests which are the same whether a document is encoded in a binary format or encoded as TJSON.
No.
