Earlier quoted context omitted.
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.
TSON – A JSON superset with immutable, hash-pinned schemas
51–60 of 68 posts
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#52I 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.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#53This looks like AI slop, and also a worse version of CUE.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#54> 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?
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#55Just 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.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#56Earlier quoted context omitted.
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...
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#57My friend you have discovered Nickel but with less types
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#58The website smells vibe-coded.
vibe-ideated too
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#59Earlier quoted context omitted.
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++)
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#60Using 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?
!!schema: { url: "https://example.com/people.tn" sha256: "c4d5e6f7…a2b3c4d5" }