Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TSON – A JSON superset with immutable, hash-pinned schemas

tson.io

Post reply on HN
Print view View original

21–30 of 68 posts

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#22

Post by hyperhello »

ltbarcly3 wrote: post #16
phailhaus wrote: post #11

Earlier quoted context omitted.

And there you go, just `[]` is no longer valid, so you need a new format.

If you need a schema for [] you have lost the plot.

Well, you could be annotating type that the array is for.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#23

Post by eska »

tonyg wrote: post #9

Absolute slop. Interesting that the end result, the place where Claude ended up, is similar to a (human-authored, windmill-tilting) project of mine, https://preserves.dev/ . Though with a much prettier website and far, far, far more words.

I unfortunately agree, this reads heavily AI generated. I was not able to follow the reasoning, e.g. management of backward and forward compatibility seems broken.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#26

Post by ramses0 »

Retr0id wrote: post #17

What's the justification for being a superset of JSON? Being incompatible with most existing JSON tooling and interfaces is a big disadvantage, so there better be a tangible upside. Also, I see mention of hashing, but no mention of canonicalization. Does fiddling with a schema's whitespace change its hash?

"superset" is just marketing mumbo jumbo that says: "I promise to embed an x86 virtual machine inside my spec that'll still parse whatever weird JSON you're currently handling and give it back to you as an object in your programming language"

    $ echo '{ "Hello": "World" }' | tson --parse
    ERROR: ...refusing to interoperate w/ JSON b/c we want to be different
...that's a non-starter. If they're trying to replace or supplement JSON (same way `uv` has been replacing / supplementing `pip`, and `deno` is doing the same with `node`), you've got to do the work of supporting the extant real-world use cases that are floating around but with a healthy layer of $BETTER sprinkled on top.

    $ echo '{ "Hello": !number 3.14 }' | jq '.'
    jq: parse error: Invalid numeric literal at line 1, column 19
...THAT's the difference/extension.

I've been explicitly trying to support `--json5` on some of my internal work tooling. Being very explicit that I'm not parsing `--json`, but instead using a slower (but more forgiving) `--json5` which would allow comments, trailing commas, whatever JSON5 claims to support.

This `--tson` feels like it's solving two problems in disguise:

1) It wants to be `--json6` (eg: `pi: !number 3.14`)

2) It wants to use it's own `--json6` (aka: `--tson`) to write "json-ish schemas" (eg: `foo: [text; 1..10]` for presumably a list of maximum of 10 elements?)

...JSON was a blessing because it existed naturally as an unambiguous "lists, dicts, values" representation that most programming languages treat as first-class citizens. Missing "sets" and things like "date" or "boolean" are certainly under-specified, but that's the real-world impact of JSON as lowest common denominator.

SCHEMA's don't have nearly as much natural, unambiguous representations across many programming languages. The closest thing I can think of is straight up Java + Constructors (ie: a full programming language for object initialization but w/o allowing interaction or behavior).

   CalendarEvent x = new CalendarEvent( Date start, Date end, Boolean all_day, List>, ...etc... )
...where my mind has gone lately is doubling down on TypeScript's `*.d.ts` as a "naturally occurring, expressive schema language". It's hella-more-complicated to parse/validate than JSON, but there's tons of tooling around it, and it's relatively unambiguous that it can solve and express Real World(tm) engineering problems.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#27

Post by geoah »

kbolino wrote: post #19

Using the query string to carry the sha256 hash but then saying the "hash parameter is verification metadata, not identity" doesn't make much sense. The ?query part of a URL is supposed to be sent to the server. If you want to add client-side (meta)data, you should use the #fragment part of a URL. See RFC 3986, sections 3.4 and 3.5: https://datatracker.ietf.org/doc/html/rfc3986#section-3.4

Was thinking the same. ?v=4#sha111 for defining the version and using fragment for hash verification seemed like a more interesting approach.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#29

Post by yourapostasy »

hmokiguess wrote: post #12

I think I'm gonna go back to XSLT

I sometimes wonder if we as an industry should revisit XML for those use cases where painful JSON contortions are being used, now that LLM's can plausibly support writing the syntax for XML-adjacent languages like XSLT without as steep a learning and sustainment curve. My natural inclination is to design to accommodate as complex a space as the business requirements project for, because representation data structures and languages are so incredibly painful to change late in a product's maturity cycle.

So I've never rejected XML out of hand, but I've always been "show me" skeptical of calls for it and pushed for explanations on why the business requirements feel the justification to adopt XML. Sometimes I've seen it totally makes sense, but with the conceptual rigor it requires in those use cases, the skillset and expertise of the development team has to reach a higher than average bar. I'm cautiously hopeful LLM's might help with lowering that bar, but time will tell.

Re: TSON – A JSON superset with immutable, hash-pinned schemas

#30

Post by al_be_back »

>> Ordering, consensus, and mutability policy are application concerns outside this series. [1]

Of course, immutable means as-is, but since you're not dealing with ordering etc (that's pretty big), I might as well use existing tech (JSON with a schema) and a policy (simple/naive: hash and compare lowercased data).

[1] From their spec: 2.2.1 Identity and Content Addressing - https://tson.io/2026/32/tson-part1-data/#

Post reply on HN