New better alterative to XML, JSON and YAML

I have read this document, and I don't really like this alternative, much. However, one consideration should be that one format is not necessarily suitable for everything; there will be differences by data model and other stuff. Different formats have different advantages and disadvantages, both in general and for specific applications.

I had recently been working on something too, called TER. It is a pure ASCII file (although some implementations might support other character sets, mine doesn't, although non-ASCII characters can still be represented using escape sequences). It can be converted to DER (a program can also be written to convert the other direction (BER to TER), but this is not done yet).

It is ASN.1X which is a variant of ASN.1; a few types are removed (OID-IRI, and a few others) and some new types are added (BCD string, TRON string, PC string, key/value list, OBJECT IDENTIFIER RELATIVE TO, and a few others), and also a few types are deprecated (such as UTCTime), although they are intended to not conflict so that it is possible to implement both in the same program if you want to do. (ASN.1X also removes or restricts some other features of ASN.1, such as that optional fields and fields with a default value are not allowed if it would require to look ahead to determine the absence or presence of the field.)

Xenon has a type for references to other nodes. I had considered (before seeing the document about Xenon) adding such a type into ASN.1X, although I had not done so yet. (My idea is to use a relative format (I have the idea how this will be encoded in DER, although I am not sure about TER; for TER it might require multiple passes, and currently the implementation uses only a single pass), that if some structure is taken out and moved to another file, and it only references within that structure, the reference will remain intact, and it cannot interfere.)

TER also uses the same comment syntax than Xenon (although, so does PostScript, and probably others too).

Perhaps another thing to be noted is PostScript notation; a subset of the PostScript notation could be used for arrays and key/value lists and some such things like that (and is something I sometimes use).

There is no mandatory bom, it's recommended, not a must

> I think the requirement for Unicode is bad in general, whether it uses BOM or not.

While there exist legitimate complaints about Unicode, I believe there is no other feasible encoding than UTF-8 for textual formats now.

> I assume it means that numbers are expected to be IEEE 64-bit floating point numbers represented in the decimal format.

I too believe so (hence the next item), but that just doesn't make sense if you ponder. IEEE 754 doesn't define any textual format while it does have binary decimal formats. The correct wording should have been that numeric scalars follow a specific grammar to be interpreted as an IEEE 754 binary64 number in the data model.

> I think that a binary format would be better as a canonical representation anyways. However, the lack of indicating the data type would seem to make it difficult to know how to convert it unless you already know the schema.

That's fair. But we have already observed textual formats being... "abused" for the cryptographic purpose (e.g. JWT), so it's not too bad either to have a canonical representation or to explain why there is no canonical representation defined.

> Xenon does have a reference type to other nodes, which is something that other similar formats don't have, though.

There are several formats that do try to support native graph types, including YAML and Concise [1]. So that is hardly new. I think Concise actually tried very hard to make it fine! But it became quite more complex as a result.

[1] https://concise-encoding.org/

Here the canonical representation refers to one single definite and unambiguous encoding for given data. This requirement is very common in cryptographic applications and also commonly demanded when the deterministic processing is desired. Technically the "canonical" and "deterministic" encoding can differ (e.g. ASN.1 CER vs. DER), but there is not much value to have two distinct encodings.

On graphs: as you've said recursive code has to be careful, but the recursion itself is not very frequent in normal applications and they are more susceptible to attacks if the recursion is built into the serialization format. XML billion laughs attack is a famous demonstration for this issue. It is still worthwhile to have parallel standards to specify how recursive structures should be encoded in the basic format, and possibly to tweak the basic format to better accommodate such standards, but I believe such needs can be met without making the basic format bigger.

Indentations are still desired for most human tasks indeed! But you can have indentations and groupings at once, one complementing each other. As you've noticed, CSON's verbatim syntax was intentionally designed so that it remains valid without any indentation but your instinct really wants to align those lines anyway. (A similar approach can be seen in Zig verbatim strings, which seem to be designed independently from CSON and make me much more confident about this choice.)