3 ms·

Lots of recursive data-structures (trees/graphs/*) lend themselves nicely to lots of nesting. Such documents aren't really intended to be read/written by humans

Lots of recursive data-structures (trees/graphs/*) lend themselves nicely to lots of nesting. Such documents aren't really intended to be read/written by humans.

vesinisa 7y ago
No, and if they can not be even read by a machine, it's bad.
cortesoft 7y ago
If they aren't meant to be read/written by humans, JSON is probably a bad choice.
- crazygringo 7y ago
  I couldn't disagree more. If you need to serialize and deserialize data between tools written in different languages -- e.g. write data to a file and read it in another tool -- then what would be better than JSON? Nothing about JSON is inherently good or bad for deeply hierarchical/recursive data.
  - shakna 7y ago
    Deeply hierarchical/recursive data is equally well served by XML and Protobuf. However, JSON itself can be... Painful for some subsets of data that you may wish to move between applications. Binary data, well-typed data. JSON tends [0] uses floats, so you may need to adjust your expectations about how to store numbers if precision matters. You can workaround a lot of these, such as through various encodings, but they are workarounds. A lot of those workarounds depend on re-encoding, which unfortunately means using strings, which can run afoul of "An implementation may set limits on the length and character contents of strings." and silently drop important bytes, or simply cut off the end of the payload. [0] The grammar is well-defined, the behaviour is not. "This specification allows implementations to set limits on the range and precision of numbers accepted." https://tools.ietf.org/html/rfc8259#page-7 https://tools.ietf.org/html/rfc8259#page-7
    - Bnshsysjab 7y ago
      Wouldn’t XML increase filesize even with compression applied? Obviously there are better machine readable libraries out there but XML is the middleground between efficiency and support
      - shakna 7y ago
        I would lean toward Protobuf wherever you can use it. It is designed to deal with issues like this. However, you can't always fulfill some of the requirements for it. In those areas, XML strikes a practical balance. Especially if you can use a significant subset of XML. (If you don't need DOM, then use a parser that doesn't produce it, etc.)
  - cortesoft 7y ago
    I would say protobuffs

Lots of recursive data-structures (trees/graphs/*) lend themselves nicely to lots of nesting. Such documents aren't really intended to be read/written by humans.

vesinisa 7y ago

No, and if they can not be even read by a machine, it's bad.

cortesoft 7y ago

If they aren't meant to be read/written by humans, JSON is probably a bad choice.

crazygringo 7y ago
I couldn't disagree more. If you need to serialize and deserialize data between tools written in different languages -- e.g. write data to a file and read it in another tool -- then what would be better than JSON? Nothing about JSON is inherently good or bad for deeply hierarchical/recursive data.
- shakna 7y ago
  Deeply hierarchical/recursive data is equally well served by XML and Protobuf. However, JSON itself can be... Painful for some subsets of data that you may wish to move between applications. Binary data, well-typed data. JSON tends [0] uses floats, so you may need to adjust your expectations about how to store numbers if precision matters. You can workaround a lot of these, such as through various encodings, but they are workarounds. A lot of those workarounds depend on re-encoding, which unfortunately means using strings, which can run afoul of "An implementation may set limits on the length and character contents of strings." and silently drop important bytes, or simply cut off the end of the payload. [0] The grammar is well-defined, the behaviour is not. "This specification allows implementations to set limits on the range and precision of numbers accepted." https://tools.ietf.org/html/rfc8259#page-7 https://tools.ietf.org/html/rfc8259#page-7
  - Bnshsysjab 7y ago
    Wouldn’t XML increase filesize even with compression applied? Obviously there are better machine readable libraries out there but XML is the middleground between efficiency and support
    - shakna 7y ago
      I would lean toward Protobuf wherever you can use it. It is designed to deal with issues like this. However, you can't always fulfill some of the requirements for it. In those areas, XML strikes a practical balance. Especially if you can use a significant subset of XML. (If you don't need DOM, then use a parser that doesn't produce it, etc.)
- cortesoft 7y ago
  I would say protobuffs