I think it looks okay, but noisy, and my main concern is that it adds so little to JSON - in particular, RJSON. The built-in token replacement MIGHT be nice, but... is token replacement part of the library itself? Or is that something applied elsewhere?

There is no need to have a digraph surrounding every element of data. Beyond being ugly, the digraphs make the file almost impossible to edit for anyone not already familiar with them. They require a large number of random symbols to be memorised. The strict typing is also not really a benefit. You can define the desired types of elements in a schema before reading data (and will need to do that anyway for validation purposes). Having the types also transcribed in the file means that writing out the file and changing the types of data would be much harder. As an example, when you force a file to specify if integers are 32-bits or 64, you make it less general (it will only work with parser that match that number of bits) and require extra data to do that. A double loss over just writing the integer out. Even if you are dedicated to strict typing, it makes more sense to do it with something along the lines of C literals (12f, 100l, etc.) because people are already used to that. This has the added benefit that the letter you put after the number is also the first letter of the type you want it to be, which is easier to remember than ^ for double and * for decimal. It's also not needed to put the identifier on both the opening and closing angle brackets. The most obvious notation would be something akin to what you might see in an assembly file, eg I32.900 for 900 as a 32-bit integer.

JSON clearly wins this comparison because people can look at the JSON and guess what it means. People aren't going to go for a more complicated format that makes less sense. I personally prefer Clojure's EDN when it comes to data formats just because it looks nicer and removes redundant syntax. I don't think there's much to be improved upon from there.

Personally, I don't see a huge upsell over JSON for interop. Typing is great, but largely mitigated by things like typescript, graphql generators etc etc. edit: and json schema

The biggest issue I see with JSON today is the inability to self reference values. Data duplication overhead is high, and deserializing doesn't work as expected if you want two objects to be reference equal.

Also, nitpick: that syntax would be a grind to write manually vs JSON.

I love that you are noodling in the open, and getting feedback / impressions early -- that's the recipe for doing something new, better!

Now, unfiltered first thoughts...

Have you used SOAP RPC and is it clear why the industry (outside of banking and financial services that depend on correctness!) largely shifted to JSONic REST?

At first exposure to this, the delimiters feel like line noise, as if SOAP and a lineprinter got together and said, "How could this offer less utility while being more opaque?"

There's a cognitive tax on something being unlike other things, which is why so many substitutions end up adopting handlebars/mustache type syntax, or so many things look like INI/TOML/YAML/etc.

Have you looked at JSON5, XML + XSLT, JSONNET and the like? What about JSON Schema and similar? ( https://json-schema.org/understanding-json-schema/reference/... )

Not saying any of those are be-all end-all, they are not. But it would be super helpful to have a "Why not X" page on your README that shows you've considered SOTA across the landscape, and why that doesn't work for you. See, for example: https://hitchdev.com/hitchstory/why-not/

Author here. Thank you SO MUCH for the comments. This is more feedback than I could have hoped for. There's no danger of this language replacing JSON or XML any time soon, but it's been a really useful exercise for learning about the issues involved in designing such a language, and this feedback helps me learn even more. I'll keep iterating with these comments in mind.

I'm reminded of XML where all the information is store in attributes.