from Hacker News

Introducing TJSON: Tagged JSON with Rich Types

by alexatkeplar on 4/25/17, 11:39 AM with 52 comments

  • by portlander12345 on 4/25/17, 5:27 PM

    Surprised no one here has mentioned Transit. It's an extensible typed data format with both JSON and binary representations. In other words, you can configure custom types, such as Immutable data structures, and they'll be automatically serialized and restored for you.

    Good intro: http://cognitect.github.io/transit-tour/

    GitHub: https://github.com/cognitect/transit-js

    Note that in the introduction they provide a simple benchmark where Transit is both more compact and faster to parse than JSON with custom hydration.

  • by keithwhor on 4/25/17, 5:07 PM

    Biggest complaint:

    Unreadable format, as mentioned in this thread.

    {"key:A<A<s>>":[["values"],["here"]]}

    This doesn't mean anything to me as a developer, unless I've seen the spec. It's kludgy. It's not reverse-compatible if you don't install a TJSON parser.

    Two solutions immediately strike me as better, one has been mentioned here.

    (1) Not optimal, but actually spell out words in key names. There's no reason "A" has to mean Array. That doesn't mean anything to me. If I'm seeing it for the first time and have no idea what TJSON is, the very next value could be "key2:B<B<t>>".

    (2) Far more optimal: as an example has been provided with "date", just nest objects as values for any extended types. Then this spec is completely reverse compatible and compliant, and as a developer I don't have to worry about parsing key names.

    e.g.

      {
    "some_nested_array": {
      "type": "array.array.string",
      "value": [
        ["values"],
        ["here"]
      ]
    }
  }
    Extremely easy to implement and not reliant on a governing body.

  • by tobltobs on 4/25/17, 4:48 PM

    Dear JS Hipsters, even if you all suffer from NIHS, could you please take look at XML before you invent another format. I am sure you will get used to those square brackets.

  • by laurent123456 on 4/25/17, 4:12 PM

    I'm curious what would be the use case for this? JSON is a human readable/writable format, however this kind of syntax is not anymore: "{"nested-array:A<A<s>>": [["Nested"], ["Array!"]]}"

    So it feels more like a machine format, but in that case why not use a more efficient one, like a binary format?

  • by hajile on 4/25/17, 5:11 PM

    If you're making it unreadable with types, you might as well switch to a statically typed binary JSON format like bson or ubjson instead. You get smaller files, faster parsing, partial parsing (skip what you don't need), and (in some implementations) streaming of large files.

    http://ubjson.org/

    http://bsonspec.org/

  • by escherize on 4/25/17, 4:45 PM

    Edn seems like a better solution here. Not o ly is the tagging more straightforward (wow not embedded in a string?), But you can write your own tags for custom types.

  • by user5994461 on 4/25/17, 4:54 PM

    If you want JSON with type checking, use a json schema.

    http://json-schema.org/examples.html

    Been there for almost a decade. Already supported by all the major json libraries in all the major languages.

  • by ungzd on 4/25/17, 4:48 PM

    This is literally hungarian notation for JSON.

  • by dolmen on 4/25/17, 5:30 PM

    As any normal JSON document is not a valid TJSON document (and worse, some JSON document may be valid TJSON documents but TJSON imposes a different interpretation) using the "JSON" suffix is just misleading.

  • by pfooti on 4/25/17, 4:22 PM

    literally the only use case I see here is dates. Like everything else I can infer the type of the field based on its contents. "boolean": false, no kidding. "event_ts": 1223349483, is that an index number or milliseconds since epoch or what? Well, probably ms since epoch, but my one gripe about json is that there's no good way to push dates without domain knowledge (anything whose property name ends in _at or _ts gets converted? all numbers in a certain range get converted?)

  • by dep_b on 4/25/17, 5:22 PM

    Backward compatibility seems terrible to me. A regular JSON parser will produce garbage from this since variable names are changed while an XML parser parsing without any context how to parse specific fields will still provide correct data. Your dates might remain strings for example but the string is still correct.

  • by TazeTSchnitzel on 4/25/17, 6:25 PM

    I question the value of the tags where they state the obvious. Does this

      {"foo:O":{}}
    really tell you more than

      {"foo":{}}
    ?

    The ability to encode sets, integers, binary data and time stamps is useful. But why tag things which are what they look like? It's a waste of space.

  • by zwerdlds on 4/25/17, 4:15 PM

    Anyone care to give a first blush comparison vs protobuffs/json schema?

  • by panic on 4/25/17, 6:19 PM

  • by keredson on 4/25/17, 5:53 PM

    Why would you define the type of something in the PARENT object?

  • by Entangled on 4/25/17, 6:18 PM

    I prefer YAML no matter how much lipstick you put on JSON.