5 ms·

If hashing is the main concern, wouldn't a "strict" spec for JSON do the job? eg. "all keys must be sorted", "all dates must be ISO-xxx", etc.?

bascule 10y ago
You're describing canonicalization, which incorporates elements of the encoding format into the final hash, and therefore does not facilitate retaining the same content hash when transcoding to different formats. Also, canonicalization is a bit of a mess. There are several incompatible canonicalization schemes for JSON, and even within a single one of those people have a difficult time implementing them correctly. See e.g. https://github.com/theupdateframework/tuf/issues/362 https://github.com/theupdateframework/tuf/issues/362
- dolmen 10y ago
  So you are just creating another non-interoperable canonicalization format that takes out from JSON everything that makes it great: terseness. https://xkcd.com/927/ https://xkcd.com/927/
  - bascule 10y ago
    You seem to have missed the point: it's not a canonicalization format. Content-aware hashing is a more powerful alternative to canonicalization which avoids many of the problems involved in designing a canonicalization scheme.
  - jerf 10y ago
    I'm not sure what you mean by "terseness". Do you mean the size of the spec? Because as serialization formats go, it is on the short side. However, typical JSON data is anything but terse; it is almost the most verbose serialization format in use, beaten out only by XML. Which I suppose could be where you're getting the idea that it is terse from, but in that case, it is "terse" only in the sense that it is the second worse of all the couple dozen common formats. It's kind of like how I've said a couple of times on HN that new compiled language designers should be grateful to C++ for setting the bar for compilation speed so low; it makes it very easy to put "compiles more quickly that C++!" into the initial elevator pitch. However, you are not "fast" merely by beating the slowest, nor are you "terse" merely by being slightly more efficient than the worst.
    - dolmen 10y ago
      Can we at least agree that TJSON is more verbose than JSON?
- seagreen 10y ago
  Have you seen my Son project? (https://github.com/seagreen/Son https://github.com/seagreen/Son) I think I may have gotten JSON canonicalization right. Also, I'm collecting a list of all subsets of JSON here if anyone knows of more: https://housejeffries.com/page/7 https://housejeffries.com/page/7 EDIT: Wow there's a lot of criticism in this thread. For the record I think TJSON is great.

bascule 10y ago

You're describing canonicalization, which incorporates elements of the encoding format into the final hash, and therefore does not facilitate retaining the same content hash when transcoding to different formats. Also, canonicalization is a bit of a mess. There are several incompatible canonicalization schemes for JSON, and even within a single one of those people have a difficult time implementing them correctly. See e.g. https://github.com/theupdateframework/tuf/issues/362 https://github.com/theupdateframework/tuf/issues/362

dolmen 10y ago
So you are just creating another non-interoperable canonicalization format that takes out from JSON everything that makes it great: terseness. https://xkcd.com/927/ https://xkcd.com/927/
- bascule 10y ago
  You seem to have missed the point: it's not a canonicalization format. Content-aware hashing is a more powerful alternative to canonicalization which avoids many of the problems involved in designing a canonicalization scheme.
- jerf 10y ago
  I'm not sure what you mean by "terseness". Do you mean the size of the spec? Because as serialization formats go, it is on the short side. However, typical JSON data is anything but terse; it is almost the most verbose serialization format in use, beaten out only by XML. Which I suppose could be where you're getting the idea that it is terse from, but in that case, it is "terse" only in the sense that it is the second worse of all the couple dozen common formats. It's kind of like how I've said a couple of times on HN that new compiled language designers should be grateful to C++ for setting the bar for compilation speed so low; it makes it very easy to put "compiles more quickly that C++!" into the initial elevator pitch. However, you are not "fast" merely by beating the slowest, nor are you "terse" merely by being slightly more efficient than the worst.
  - dolmen 10y ago
    Can we at least agree that TJSON is more verbose than JSON?
seagreen 10y ago
Have you seen my Son project? (https://github.com/seagreen/Son https://github.com/seagreen/Son) I think I may have gotten JSON canonicalization right. Also, I'm collecting a list of all subsets of JSON here if anyone knows of more: https://housejeffries.com/page/7 https://housejeffries.com/page/7 EDIT: Wow there's a lot of criticism in this thread. For the record I think TJSON is great.