Hash-pinned schemas are definitely the right direction for ensuring verifiable provenance across distributed systems. Great concept!

why can't you use hash pinned schemas with existing json? Why do you need a new format for it?

    {
        'schema': 'c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2',
        'data': []
    }

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.

If the author is here, the Github repo in https://litterat.io/ should be https://github.com/litterat

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 think I'm gonna go back to XSLT

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...

great another shitty JSON variant. now I'll have 9 different json-like libraries in every project that I can't get rid of.

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?

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

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.