4 ms·

Why don't float types use a tagged string? It says "tagging is mandatory" in the initial document, but floating point types are then omitted in the official spe

by kr0 10y ago

Why don't float types use a tagged string? It says "tagging is mandatory" in the initial document, but floating point types are then omitted in the official spec

jerf 10y ago
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.
- bascule 10y ago
  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. The spec does this here: https://www.tjson.org/spec/#rfc.section.4.3 https://www.tjson.org/spec/#rfc.section.4.3 4.3. Floating Points All numeric literals which are not represented as tagged strings MUST be treated as floating points under TJSON. This is already the default behavior of many JSON libraries. 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. As noted in the post (which names a similar list of binary formats), TJSON is intended to be supplemental to binary formats, not a "replacement"
  - jerf 10y ago
    Thank you. I skimmed over that accidentally. Good.
- deleted 10y ago
  [deleted]
wojcikstefan 10y ago
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" }`?
- kr0 10y ago
  This. From a purely semantic point of view it seems odd
bascule 10y ago
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/objecthash.py#L56 https://github.com/benlaurie/objecthash/blob/master/objectha...
bascule 10y ago
I've opened an issue about using tagged strings for floats here: https://github.com/tjson/tjson-spec/issues/32 https://github.com/tjson/tjson-spec/issues/32

by kr0 10y ago

Why don't float types use a tagged string? It says "tagging is mandatory" in the initial document, but floating point types are then omitted in the official spec

jerf 10y ago

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.

bascule 10y ago
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. The spec does this here: https://www.tjson.org/spec/#rfc.section.4.3 https://www.tjson.org/spec/#rfc.section.4.3 4.3. Floating Points All numeric literals which are not represented as tagged strings MUST be treated as floating points under TJSON. This is already the default behavior of many JSON libraries. 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. As noted in the post (which names a similar list of binary formats), TJSON is intended to be supplemental to binary formats, not a "replacement"
- jerf 10y ago
  Thank you. I skimmed over that accidentally. Good.
deleted 10y ago
[deleted]

wojcikstefan 10y ago

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" }`?

kr0 10y ago
This. From a purely semantic point of view it seems odd

bascule 10y ago

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/objecthash.py#L56 https://github.com/benlaurie/objecthash/blob/master/objectha...

bascule 10y ago

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