> If you need to debug it, it's trivial to even look at the hex dump of packets.
The problem, of course, is that it's not trivial to generate those packets in an interactive fashion. That's what's great about protocols such as SMTP & HTTP: you can learn them just by telnetting to a port.
Of course, there are advantages to TLV formats, which is probably a reason why Ron Rivest invented canonical S-expressions, which enable both a readable symbolic form (e.g. (foo bar baz)) and a fast-parsing canonical form (e.g. (3:foo3:bar:baz)), as well as forms for hex (e.g. (#666f6f# #626172# #62617a#)) and base64 (e.g. (|Zm9v| |YmFy| |YmF6|)) transmission. The intended use case was to transmit tagged data like public keys:
(public-key
(rsa-pkcs1-md5
(e #03#)
(n
|ANHCG85jXFGmicr3MGPj53FYYSY1aWAue6PKnpFErHhKMJa4HrK4WSKTO
YTTlapRznnELD2D7lWd3Q8PD0lyi1NJpNzMkxQVHrrAnIQoczeOZuiz/yY
VDzJ1DdiImixyb/Jyme3D0UiUXhd6VGAz0x0cgrKefKnmjy410Kro3uW1|)))
which could be transmitted in an efficient format (base64-decode the following to see what it'd look like):
Of course, since it was eminently readable and part of an eminently well-thought-out standard, the thing completely died on the vine, and now we're stuck with JSON and XML and YAML and why do I even bother getting up in the morning computing is so backwards it's not even funny.
Seems pretty obvious to me, why that failed - the linked specification describes how to represent a tree of pairs of byte strings. What do I do with that? That's not much more helpful than saying that I can encode my information as a sequence of zeros and ones.
It is redundant and vague. Why six ways to represent a byte string? Or even more if you count things like quoted strings and length prefixed quoted strings separately. It has the feel of just do whatever you want. As some kind of type information one can associate display hints with each byte string. What are valid display hints? Arbitrary byte strings, of course. »Many of the MIME types work here.«
Where would you even start to build a useful library around this specification? It is so general that it is useless.
> Seems pretty obvious to me, why that failed - the linked specification describes how to represent a tree of pairs of byte strings. What do I do with that?
Whatever you want to. Once you have lists, trees and byte strings, you have everything you need (note that JSON is this, with some sugar for alists).
> Why six ways to represent a byte string?
Because different approaches make sense in different contexts: for a single word the word itself is completely fine; for an English phrase "this is a small phrase" works; for certain constants hex works, e.g. #DEADBEEF#; for large binary strings then Base64 encoding works, since it's opaque anyway. And all of that is really for display: for transmission (and cryptographic hashing) the length-prefixed canonical form works perfectly, but is still visually-inspectable in time of need (unlike, say, a pure-binary format).
> It has the feel of just do whatever you want.
It's a tool for one's toolbox, not a finished product: you use it to build whatever you want.
> Where would you even start to build a useful library around this specification? It is so general that it is useless.
How does one build a useful library around JSON? Canonical S-expressions live at the same level of abstraction (but are efficient and visually appealing, unlike JSON).
Are you aware that S-expressions are how Lisp code is represented? This takes that same universal code format and turns it into a universal data format. How would you build a library around it? How do Lisp implementations build a useful library around S-expressions? Simple: they offer functions like READ to read in structured data, and functions like EVAL to evaluate it as code. Likewise, the user of canonical S-expressions would have some library to read in the expressions, and some other library (or his own code) to evaluate that structured data as code in whatever format he's using.
I point you to the SPKI RFCs as an example.
In the context of the parent to my post, one can use S-expressions as an alternative to tag-length value. Instead of 0x01666f6f20626172, one might have (name "foo bar") as something a human being can read & write, which encodes down to (4:name7:foo bar), which is fast to parse, reasonably efficient for transmission, and can be read by a human in duress. And if for some reason one wanted a copy-pastable version (maybe for end users to paste auth tokens, or to survive emails, or something) then one could use {KDQ6bmFtZTc6Zm9vIGJhcik} (that's just Base64-encoded).
Or you could use JSON: {"name": "foo bar"}. Which is larger, more error-prone to type, uglier, harder to parse, and still needs to be evaluated in its context anyway (What if name isn't the only required attribute? What if it must be in HTML format? &c. &c. &c.).
I don't think that canonical S-expressions and JSON are really on the same level. JSON enforces much stricter structure or constraints - key value pairs with string keys and a small set of possible value types, numbers, strings, booleans, arrays, you name it. You have to build all of this on top of canonical S-expressions, you get two byte sequences, the display hint and the actual value, and then it's your task to interpret the raw byte sequences. It's also your task to figure out whether a list of pairs represents a map or a list of items with two values. It's definitely a powerful format but in order to be able to use it, you have to first build a lot of additional functionality on top of it. And by the way, this is not a mindless defense of JSON, I prefer to stay away from all things JavaScript as far as I can.
The problem, of course, is that it's not trivial to generate those packets in an interactive fashion. That's what's great about protocols such as SMTP & HTTP: you can learn them just by telnetting to a port.
Of course, there are advantages to TLV formats, which is probably a reason why Ron Rivest invented canonical S-expressions, which enable both a readable symbolic form (e.g. (foo bar baz)) and a fast-parsing canonical form (e.g. (3:foo3:bar:baz)), as well as forms for hex (e.g. (#666f6f# #626172# #62617a#)) and base64 (e.g. (|Zm9v| |YmFy| |YmF6|)) transmission. The intended use case was to transmit tagged data like public keys:
which could be transmitted in an efficient format (base64-decode the following to see what it'd look like): Of course, since it was eminently readable and part of an eminently well-thought-out standard, the thing completely died on the vine, and now we're stuck with JSON and XML and YAML and why do I even bother getting up in the morning computing is so backwards it's not even funny.http://people.csail.mit.edu/rivest/Sexp.txt