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
I'm not sure why string level manipulations would be necessary in a structured data format to begin with. You'll update the URL using tooling regardless, so why not utilize the language for it at the expense of a little bit of verbosity?
Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.
Yes, this is just how fragments work; they're supposed to be stripped before sending the request to the server. This is exactly why, in the context of the thread, the fragment is the correct place to put the TSON hash parameter.
It is fine to have the fragment stripped before sending it to the server. What I meant was that client-side parsing of TSON in many languages will be hindered by the client-side libraries stripping the fragment far too early. Because you will need that fragment part for validation, but if your parse_url-function dismisses the fragment because nobody ever needs it...
I did a cursory look through a number of major languages and libraries*, and as far as I can tell, they all retain and provide access to the fragment by default. Maybe some of them didn't in the past, or the APIs that I found superseded older ones that didn't, but at least in the present day, this doesn't seem to be an issue.
* = Including urllib.parse (Python), url_parse (PHP), java.net.URI (Java), System.Uri (.NET), net/url.URL (Go), curl_url_get (libcurl), URL (JavaScript, which calls it the "hash"), url::Url (Rust), Boost.URL (C++)
No comments means that one cannot use it for configuration. Properties repeat the XML mistake of the attribute/content dichotomy.
And trailing commas as a syntax error prevents easy sorting/appending/editing of arrays.
And it doesn't fix a ton of JSON problems like strings containing newlines, quotes and the like, while introducing a ton of new problems, like the dependency on obscure Unicode features to elide quotes. This will lead to TSON homoglyph attacks.
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.
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<Invitee<...>>, ...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.
> TSON (Typed Schema Object Notation) is a schema system with immutable, hash-pinned schemas whose definitions are themselves data. A document names its schema, the schema names its meta-schema; one hash verifies the whole chain. The finishing touch, TSON's data format is a Unicode-first superset of JSON you'll actually enjoy writing.
I'm not sure what problem this is solving?
I rarely have issues with JSON schema validation; and when I do, the failure patterns aren't something that I want to offload to a 3rd party library.
Basically, how my application fails with poorly formed JSON is part of how I define my application, which means that unexpected JSON needs to be handled on a case-by-case basis.
---
Anyway, the system smells like xsd, which when I used it, wasn't worth the effort.
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.
I think the industry has an XML-shaped hole for sure, but XML itself was still designed before about 30 years of hard-won knowledge about smart design of data languages.
you can just add schema to json why add new syntax now, especially for json I dont think it makes sense I honestly believe the war is over there won't be a xml to json moment unless we move to a new platform other than browsers which seem rather unlikely, json honestly is fine for something that's somewhat human readable...
This has been a solved problem for at least two decades. Use ASN.1 and choose your encoding rules accordingly: JER when you need JSON, XER when you need XML, and switch to BER/DER when you need to reduce transfer costs.
>> 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).
Seems like it draws a lot of inspiration from EDN. Tagged literals, commas-as-whitespace (and optional), and anything-can-be-a-key are features I sorely miss when I have to go back to JSON.
Don't know how I feel about optional quotes around strings, that seems like a mistake. And having an immutable set literal would be nice as well.
Because I may not be the only one who was confused initially: I think EDN in this instance refers to the data serialization format (Extensible Data Notation) from the Clojure people, not to CBOR-EDN (Extended Diagnostic Notation), which also offers tagged literals and anything-can-be-a-key, IIRC.
I just use Amazon Ion as my JSON superset of choice for my own sanity, and downconvert to JSON when (if) it matters, it's not even bad and it supports comments. Hell there's a freaking Lisp for it now, too (Fusion). https://ion-fusion.dev/
Given also that it's a big tech technology I am going to wager that it's not going away anytime soon.
I wonder where this should fit in?
It introduces itself as
> Data with an immutable schema.
But for what? I don't see a fit for APIs here, maybe config but there are already other languages that are perfectly suited for this job.
Also this feels more like some proposal than a serious attempt to build a new format. Java is widely used but I would at least expect such a new format to at least release with Java-/TypeScript, Go and Python libraries (personal perference: Rust too). But just a Java launch is at best a PoC.
Are you serious? Do you honestly think that I am talking about a schema for passing empty lists around?
If you are passing around lists of structured objects, I need you to send me what those objects are supposed to look like even if the list is empty sometimes. If you say "ok so sometimes I'll give you an object with a schema key and a list of data, other times I will just give you an empty list because I don't feel like it", everyone will hate you.
That's because you're trying to snarkily jump into a conversation you don't understand.
User `flanked-evergl` is asking why do you need a whole new format for this instead of just using json. And the answer is because everyone needs to agree on how to specify the format in the json, which `crote` suggests is as simple as doing `{"schema": ..., "data": ...}`.
There's your format. If you want everyone to agree on the `{"schema": ..., "data": ...}` pattern, you can no longer accept just `[]` as a return type. Every response has to include the `schema` and `data` keys.
My thoughts exactly. I don't mind AI coding, but I'm not really sure on the viability of anyone using or even hearing of TSON. This is just not something you do without an RFC and adoption.
Schemas, etc. look a lot like JSON-LD. You would need to pin the schema only if you're worried someone might modify one. But it gives you a lot of options out of the box, while still being valid JSON.
> Version 2 just added a new required email field to the person record. In mutable schema systems, adding a new required field is universally forbidden. The API guidelines for Google, Microsoft and Zalando all ban the practice. Protobuf even marks the required keyword a hazard developers must avoid. These rules exist because a single definition is forced to serve every document ever written against it. TSON removes this burden because schemas are immutable. A version is simply a new document with a new hash. Two contracts coexist at full strength, and employee composing person inherits the new requirement in the same declaration.
I don't understand how this helps. That just means I have dozens of schemas for the same data set. How is that better? I'd rather have one lowest common denominator schema for the entire data set and be forced to validate.
I mean I guess because the data blob specifies its own schema I can use that schema to ensure the blob is valid but then what. What is my code that processes this data supposed to do? `if(schema1) { ... } else if(schema2) { ... }`. How is that better?
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.
> Protobuf even marks the required keyword a hazard developers must avoid. These rules exist because a single definition is forced to serve every document ever written against it. TSON removes this burden because schemas are immutable.
I personally don't have a problem with them. They've grown on me. Thought they looked icky before I actually had to use them. Now I see their merit.
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
I'm not sure why string level manipulations would be necessary in a structured data format to begin with. You'll update the URL using tooling regardless, so why not utilize the language for it at the expense of a little bit of verbosity?
Was thinking the same. ?v=4#sha111 for defining the version and using fragment for hash verification seemed like a more interesting approach.
Fragments are useless outside a browser and lead to problems. A lot of command line and library HTTP agents ignore the fragment part of an URL, so you often might encounter everything after # stripped. Thus forcing you to invent yet another HTTP client/agent/URL library in a ton of languages.
Yes, this is just how fragments work; they're supposed to be stripped before sending the request to the server. This is exactly why, in the context of the thread, the fragment is the correct place to put the TSON hash parameter.
It is fine to have the fragment stripped before sending it to the server. What I meant was that client-side parsing of TSON in many languages will be hindered by the client-side libraries stripping the fragment far too early. Because you will need that fragment part for validation, but if your parse_url-function dismisses the fragment because nobody ever needs it...
I did a cursory look through a number of major languages and libraries*, and as far as I can tell, they all retain and provide access to the fragment by default. Maybe some of them didn't in the past, or the APIs that I found superseded older ones that didn't, but at least in the present day, this doesn't seem to be an issue.
* = Including urllib.parse (Python), url_parse (PHP), java.net.URI (Java), System.Uri (.NET), net/url.URL (Go), curl_url_get (libcurl), URL (JavaScript, which calls it the "hash"), url::Url (Rust), Boost.URL (C++)
Dislike.
No comments means that one cannot use it for configuration. Properties repeat the XML mistake of the attribute/content dichotomy.
And trailing commas as a syntax error prevents easy sorting/appending/editing of arrays.
And it doesn't fix a ton of JSON problems like strings containing newlines, quotes and the like, while introducing a ton of new problems, like the dependency on obscure Unicode features to elide quotes. This will lead to TSON homoglyph attacks.
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"
...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. ...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).
...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.> unambiguous
But it's pretty ambiguous when parsing. Like a long number -- is it a floating point, BigInt or i128? Every language is different
JSON was a blessing because it was literally Javascript. It was unambiguous in Javascript only.
A true unambiguous would be "everything is a string", like TCL.
Tcl brings with it some other ambiguity when serializing though.
Should the above be serialized as a dict, a list, or a string (ignoring the various possibilities of treating ints as strings themselves):That's not what superset means. Taking it at face value, all JSON is valid TSON, and some TSON happens to be valid JSON but not in the general case.
What problem is this trying to solve?
> Data with an immutable schema.
> TSON (Typed Schema Object Notation) is a schema system with immutable, hash-pinned schemas whose definitions are themselves data. A document names its schema, the schema names its meta-schema; one hash verifies the whole chain. The finishing touch, TSON's data format is a Unicode-first superset of JSON you'll actually enjoy writing.
I'm not sure what problem this is solving?
I rarely have issues with JSON schema validation; and when I do, the failure patterns aren't something that I want to offload to a 3rd party library.
Basically, how my application fails with poorly formed JSON is part of how I define my application, which means that unexpected JSON needs to be handled on a case-by-case basis.
---
Anyway, the system smells like xsd, which when I used it, wasn't worth the effort.
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.
I think the industry has an XML-shaped hole for sure, but XML itself was still designed before about 30 years of hard-won knowledge about smart design of data languages.
If you want to know how I would approach designinga language to fill XML's market niche, check out https://docs.bablr.org/guides/cstml
Always tempted, but never enough.
you can just add schema to json why add new syntax now, especially for json I dont think it makes sense I honestly believe the war is over there won't be a xml to json moment unless we move to a new platform other than browsers which seem rather unlikely, json honestly is fine for something that's somewhat human readable...
A change in the direction of protobufs to reduce serialization and transfer costs of data exchange seems most likely the next trend.
This has been a solved problem for at least two decades. Use ASN.1 and choose your encoding rules accordingly: JER when you need JSON, XER when you need XML, and switch to BER/DER when you need to reduce transfer costs.
>> 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/#
Seem to different from JSON to be an easy drop in, while still having the problems of json. I’d rather use something further away like cue.
cue? what is that? i remember only cue which holds audio tracks metadata.
https://cuelang.org/docs/reference/spec/
I’ve used it once for something small. It was ok, but the docs and some of the libraries were a bit lacking.
But it demonstrates the kind of things you could have if you don’t care about text/parser compatibility with json
when will be xson invented, with support of xpathson and xsdson but strictly leaving out other xml features.. for future improvement?
Seems like it draws a lot of inspiration from EDN. Tagged literals, commas-as-whitespace (and optional), and anything-can-be-a-key are features I sorely miss when I have to go back to JSON.
Don't know how I feel about optional quotes around strings, that seems like a mistake. And having an immutable set literal would be nice as well.
Because I may not be the only one who was confused initially: I think EDN in this instance refers to the data serialization format (Extensible Data Notation) from the Clojure people, not to CBOR-EDN (Extended Diagnostic Notation), which also offers tagged literals and anything-can-be-a-key, IIRC.
Really unfortunate naming
If the author is here, the Github repo in https://litterat.io/ should be https://github.com/litterat
What problem does it solve? The hero of the website doesn't answer.
I just use Amazon Ion as my JSON superset of choice for my own sanity, and downconvert to JSON when (if) it matters, it's not even bad and it supports comments. Hell there's a freaking Lisp for it now, too (Fusion). https://ion-fusion.dev/
Given also that it's a big tech technology I am going to wager that it's not going away anytime soon.
I wonder where this should fit in? It introduces itself as
> Data with an immutable schema.
But for what? I don't see a fit for APIs here, maybe config but there are already other languages that are perfectly suited for this job.
Also this feels more like some proposal than a serious attempt to build a new format. Java is widely used but I would at least expect such a new format to at least release with Java-/TypeScript, Go and Python libraries (personal perference: Rust too). But just a Java launch is at best a PoC.
> I don't see a fit for APIs here
Baically protobuf, Cap’n Proto, msgpack, Avro, or every other serialization approach that versions schemas?
why can't you use hash pinned schemas with existing json? Why do you need a new format for it?
Here's some json: []
How do you add schema info to that?
Like this:
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.
It's the schema's root type, obviously.
What record types are valid to add to that array?
Don't ask me, ask the schema.
Are you serious? Do you honestly think that I am talking about a schema for passing empty lists around?
If you are passing around lists of structured objects, I need you to send me what those objects are supposed to look like even if the list is empty sometimes. If you say "ok so sometimes I'll give you an object with a schema key and a list of data, other times I will just give you an empty list because I don't feel like it", everyone will hate you.
I assumed you meant empty list because that made sense. What you said here does not make sense.
That's because you're trying to snarkily jump into a conversation you don't understand.
User `flanked-evergl` is asking why do you need a whole new format for this instead of just using json. And the answer is because everyone needs to agree on how to specify the format in the json, which `crote` suggests is as simple as doing `{"schema": ..., "data": ...}`.
There's your format. If you want everyone to agree on the `{"schema": ..., "data": ...}` pattern, you can no longer accept just `[]` as a return type. Every response has to include the `schema` and `data` keys.
Oh guilty as charged, thank you for explaining it.
If you need to embed the schema in the document, Don't design your schema in way that makes it impossible to embed the schema in the document.
[1]: https://json-schema.org/learn/miscellaneous-examples
The website smells vibe-coded.
My thoughts exactly. I don't mind AI coding, but I'm not really sure on the viability of anyone using or even hearing of TSON. This is just not something you do without an RFC and adoption.
vibe-ideated too
Schemas, etc. look a lot like JSON-LD. You would need to pin the schema only if you're worried someone might modify one. But it gives you a lot of options out of the box, while still being valid JSON.
Hash-pinned schemas are definitely the right direction for ensuring verifiable provenance across distributed systems. Great concept!
Agree. It’s early stages, but I love the approach!
Not sure if I am the only one feeling this way, but what problem is being solved with this?
> Version 2 just added a new required email field to the person record. In mutable schema systems, adding a new required field is universally forbidden. The API guidelines for Google, Microsoft and Zalando all ban the practice. Protobuf even marks the required keyword a hazard developers must avoid. These rules exist because a single definition is forced to serve every document ever written against it. TSON removes this burden because schemas are immutable. A version is simply a new document with a new hash. Two contracts coexist at full strength, and employee composing person inherits the new requirement in the same declaration.
I don't understand how this helps. That just means I have dozens of schemas for the same data set. How is that better? I'd rather have one lowest common denominator schema for the entire data set and be forced to validate.
I mean I guess because the data blob specifies its own schema I can use that schema to ensure the blob is valid but then what. What is my code that processes this data supposed to do? `if(schema1) { ... } else if(schema2) { ... }`. How is that better?
My friend you have discovered Nickel but with less types
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.
Getting flashback to coffeescript
Just use protos?
Author doesn't like protos.
> Protobuf even marks the required keyword a hazard developers must avoid. These rules exist because a single definition is forced to serve every document ever written against it. TSON removes this burden because schemas are immutable.
I personally don't have a problem with them. They've grown on me. Thought they looked icky before I actually had to use them. Now I see their merit.
This looks like AI slop, and also a worse version of CUE.
https://cuelang.org/
Why?
great another shitty JSON variant. now I'll have 9 different json-like libraries in every project that I can't get rid of.
Sorry, but this tool is just never going to succeed being written in Java.
[dead]