4 ms·
> I wouldn't bother turning it into a formal specification. Too late! > But you can always put JSON through a pretty-printer which puts values into canonical
by seagreen 10y ago
> I wouldn't bother turning it into a formal specification.
Too late!
> But you can always put JSON through a pretty-printer which puts values into canonical form before diffing.
Son is a starting point for building such a pretty printer. It takes care of messy details like eliminating the redundancies in string and number encoding, so all you have to do to specify the pretty-printer format is say where you want your newlines and how much to indent by.
- kornish 10y ago> Son is a starting point for building such a pretty printer. I don't understand: such pretty printers already exist (e.g. jq, which does a whole lot more [0]). If you're transmitting JSON and want to diff two documents, just pipe them into jq or another pretty-printer with key ordering, then use one of many existing line-by-line diff tools. [0]: github.com/stedolan/jq
- seagreen 10y agojq is great. You can actually see how it's used to test the reference implementation of Son here (https://github.com/seagreen/Son/blob/master/implementation/test/JQ.hs https://github.com/seagreen/Son/blob/master/implementation/t...) using `jq --compact-output --sort-keys .` Unfortunately, jq doesn't provide flags to control scientific/non-scientific notation or which characters are escaped, meaning if you want very tight control over the JSON generated it's not a full option. (Consider that the motivating example in the Son README isn't all you might want to use Son for. For instance some people need consistent hashing of serialized JSON documents).
- hyperpallium 10y ago$ echo "1." | jq . 1 jq is great, but doesn't preserve float/int distinction. There may be other canonicalization details that pretty printers don't address. It might be simpler to change jq and/or other pretty printers (though might be implementation or design reasons not to). But the other advantage of a new project like SON is positioning not engineering, in our heads, not in the code: tool for the job. If so, the page should spend more time on what that job is (for when people search for that job). And, as the jq example shows, tools not designed for this job mightn't do it exactly right. EDIT I was reading offline, so didn't see the sibling reply.
- seagreen 10y agoI love that we both started our comments with "jq is great". I hadn't seen yours either=)