Good intro: http://cognitect.github.io/transit-tour/
GitHub: https://github.com/cognitect/transit-js
Note that in the introduction they provide a simple benchmark where Transit is both more compact and faster to parse than JSON with custom hydration.
Unreadable format, as mentioned in this thread.
{"key:A<A<s>>":[["values"],["here"]]}
This doesn't mean anything to me as a developer, unless I've seen the spec. It's kludgy. It's not reverse-compatible if you don't install a TJSON parser.
Two solutions immediately strike me as better, one has been mentioned here.
(1) Not optimal, but actually spell out words in key names. There's no reason "A" has to mean Array. That doesn't mean anything to me. If I'm seeing it for the first time and have no idea what TJSON is, the very next value could be "key2:B<B<t>>".
(2) Far more optimal: as an example has been provided with "date", just nest objects as values for any extended types. Then this spec is completely reverse compatible and compliant, and as a developer I don't have to worry about parsing key names.
e.g.
{
"some_nested_array": {
"type": "array.array.string",
"value": [
["values"],
["here"]
]
}
}
I have certainly studied XML and think XML Schema did fantastic work specifying datatypes:
https://www.w3.org/TR/xmlschema11-2/#built-in-datatypes
I briefly considered adopting this work wholesale:
https://github.com/tjson/tjson-spec/issues/37
If you'd like to see that happen, please make a note of it in the issue. Thanks!
Also note: I'm not a JS hipster, I'm part of the Rust Evangelism Strike Force.
Second, XML is extraordinarily complicated. Flipping around the XML 1.0 spec (https://www.w3.org/TR/xml/) isn't really encouraging me that all of this is there for a reason. I'd love to be proved wrong though!
In contrast, RFC 7159 is incredibly short and readable: https://tools.ietf.org/html/rfc7159. The TJSON spec isn't bad either: https://www.tjson.org/spec/. Even combining both the result is still far shorter and more clear than XML.
{"hello-world:s": "Hello, world!"} → (hello-world "Hello, world!")
{"hello-base-sixteen:d16": "48656c6c6f2c20776f726c6421"} → (hello-base-sixteen #48656c6c6f2c20776f726c6421#)
{"base-sixty-four-is-default:d": "SGVsbG8sIHdvcmxkIQ"} → (base-sixty-four |SGVsbG8sIHdvcmxkIQ|)
{"hello-signed-int:i": "42"} → (some-int 42)
Ø → (some-big-int [bigint]|GY0+kwq94p4QRs2j4rHisQLgEN3zsFSZNJrgK+ZFcV0s1ShyMkMFOHip0oRuG7v+TAC7qmDaYSojFbZjNV5dSA==|)
{"hello-timestamp:t": "2016-10-02T07:31:51Z"} → (hello-timestamp [timestamp]2016-10-02T07:31:51Z)
The main inspiration for this format is SPKI/SDSI, which was based on S-expressions. As beautiful as you think the S-expression version may be over the (T)JSON, I personally blame the use of S-expressions as one of many reasons SPKI/SDSI failed to gain more widespread traction, and personally think something like TJSON is a lot more likely to gain traction than the second coming of S-expressions. This is, of course, a debatable point, but you won't find me working on Sexp-based formats any time soon.
ASN.1 of course has a sordid history in the credential space as well, often reviled by security experts as the source of frequent vulnerabilities, particularly problematic encodings like BER. I will admit OER is nice, but nobody uses OER and the IETF prefers things be standardized in terms of DER.
"Research things", yes been there, done that.
I assume the TJSON libraries throw errors if invalid types or formats are provided --- which is good, but that makes this a validator. Developers have been representing non-standard formats in JSON for years.
Google's response to JSON's limitations was the Protocol Buffer [1], and as I understand it, it's used internally relatively extensively, but there hasn't been much adoption outside of Google. JSON is just the right mix of simple + robust for the majority of use cases.
So it feels more like a machine format, but in that case why not use a more efficient one, like a binary format?
> TJSON documents are amenable to "content-aware hashing" where different encodings of the same data (including both TJSON and binary formats like Protocol Buffers, MessagePack, BSON, etc) can share the same content hash and therefore the same cryptographic signature.
TJSON is designed to facilitate documents that retain the same content hash when transcoded to/from binary formats.
http://json-schema.org/examples.html
Been there for almost a decade. Already supported by all the major json libraries in all the major languages.
{ "date": "1937-01-01T12:00:27.87+00:20" }
As you can see, JSON doesn't stop anyone from using RFC3339 to encode dates.
What I'm getting as is that a date gets serialized into JSON as either a string or a number, depending on who wrote the toJSON method, and that the consumer of that JSON needs knowledge about the schema of the data in order to properly deserialize it.
{"foo:O":{}}
{"foo":{}}
The ability to encode sets, integers, binary data and time stamps is useful. But why tag things which are what they look like? It's a waste of space.
Or, a more mundane explanation: the parser will silently clobber the name because it contains a ":"
Leaving any names untagged is ambiguous.
Besides that, in JSON Schema the schema is not bundled with the data. This is a feature for input validation: the receiver must know what it allows, not just what is received. This is a feature for readability (which is a great feature of JSON) as the data is not uncumbered with the schema. A receiver is free to use a schema or not. While TJSON imposes a receiver to recognize its dirty format.
So TJSON brings nothing new, except interoperability problems.