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 alr

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.