Floating point types are tagged by the use of the floating point grammar. It would require the standard to be clear that the only way to indicate integers is via "i:288", though, or there will be ambiguity.

I don't know if that circle can be squared, either; if you require integers to use the tagged string, it isn't really backwards compatible any more. If you don't, the floats remain ambiguous.

Given that the text of the blog post suggests, probably correctly, that new parsers will be necessary to use this format, I'm not convinced that trying to reuse JSON's grammar is that advantageous. If I'm switching parsers, the competition is no longer JSON, it's the full range of possible replacements, including Protocol Buffers, Cap'n Proto, XML, BSON, and everything else. If you're willing to replace parsers there's probably already something out there for you.

I had the same thought. It seems inconsistent/confusing that everything else has its type defined by the tag prefix, except for floats. Why not `{ "s:float": "f:42.0" }`?

Floating points already have a distinct type. Many JSON parsers already convert number literals to floats in all cases. For ones that emit a mixture of integers and floats, converting to a float consistently is a simple transform.

Floats are not typically used in the intended contexts for TJSON (cryptographically authenticated data), and normalizing them is rather difficult: https://github.com/benlaurie/objecthash/blob/master/objectha...

I've opened an issue about using tagged strings for floats here: https://github.com/tjson/tjson-spec/issues/32