New better alterative to XML, JSON and YAML

Because English is the global lingua franca

> I like to hear why then

Unlike Unicode xᴇɴᴏɴ must be defined in one grammar. Having special names, like $type, and hoping no language uses them is fragile.

You are being criticized for quality and your response is to fixate on one parameter being better. It's as if you were overweighing that parameter or ignoring the other million of parameters, which is what makes your proposal so out of place.

Suppose that you come to the world economic forum, and you propose a new coin you call the GeneThomas coin. When people criticize or laugh about your idea, you respond that "The coin IS greener! It really is and I can prove it". Man, you are just showing that you don't understand anything about what makes a currency good or popular.

Just find your niche in green coins, but don't try to compete with the US dollar or bitcoin cause you'll lose

• Terse.

Xᴇɴᴏɴ is as terse as ᴊꜱᴏɴ using 3 characters per scalar value rather than ”key”:value, (4) or ”key”:”value”, (6). Xᴇɴᴏɴ is significantly more terse than xᴍʟ value (5+len(key)) around 10.

• Readable multiple line indented text.

ᴊꜱᴏɴ does not support multiple line text, forcing one to escape newlines as ‘\n‘. xᴍʟ looks messy with multiline line text as the text is copied verbatim, indenting is therefore from the left of the page. Xᴇɴᴏɴ allows one to indent text more than the enclosing markup.

Native support for arrays

Awkward in xᴍʟ.

• Native support for a graph structure, elements may have multiple parents.

Both missing from ᴊꜱᴏɴ and xᴍʟ where special fields are layers on top of the markup.

• Native support for a types used in serialization.

Also missing from ᴊꜱᴏɴ and xᴍʟ.

• Unambiguous choice of data structure.

No attributes.

• Efficient to write by hand.

see Terse. Also supports comments unlike ᴊꜱᴏɴ.

• Can be implemented to be blazingly fast or using a mode-less tokenizer.

Design decisions took performance and grammar simplicity into account.

• The xenon document is named.

Useful. One can see that the document is a or

Unless a serialization/deserialization tool supports property name overriding which is trivial.

> It DOES have native graph support that xᴍʟ and ᴊꜱᴏɴ do not.

Again, how is this different from `xml:id` that is referenced from other XML document nodes and what makes it "native graph support"?

> Both Xᴇɴᴏɴ libraries can provide support for encoding say ɢᴜɪᴅs. > Better than ᴊꜱᴏɴ which does not do timestamps.

Better?

There is just no need. For what? These two can be controlled by optional schemas that may be extensible like types to validate in XML Schema or Relax NG. Schemas do not dictate format and you don't need your format to be a schema. I still can't get what makes timestamps (and GUIDs) so special so that they have special sections in your document.

I tend I think JSON also has a design flaw providing first-class support for booleans and numbers in terms of literals it took from JavaScript because the latter needs more complex syntax as a programming language. Ridiculously, XML seems to be perfect in this case unifying scalar values: whatever scalar it encodes, text representation can encode it in any efficient format regardless it is a boolean, number (integer, "real", complex, whatever special), a "human-text" string, timestamp or whatever else; HTML attribute values unlike XML don't even need to be quoted in some trivial cases and even may be omitted for boolean attributes. The application simply parses/decodes its data and manages how the data is deserialized. That's all it needs.

I would probably be happy if, say, there would be a format as simple/minimalistic as possible not even requiring delimiters like or quoted strings unless they are ambiguous. Say, `[foo 'bar baz' foo\ bar Zm9vYmFyCg== 2.415e10 ∞ +Inf -∞ -Infinity \[qux\] +1\ 123\ 456789 978012345678 {k1 v1 k2 v2} aa512e8ecf97445eac10cb5a5ea3ef63 c8a0ebbd 2026-09-24T16:45:22.5383742 P3Y6M4DT12H30M5S]` or similar, maybe with nodes metadata and comments support. The above dumb format covers arrays/lists/sets, strings `foo`, space-containing `bar baz`, `foo bar` strings in human and Base64 encoding, the `2.415e10` number from your document and both four infinity notations, a single string `[qux]` and not a nested array with a single element, a phone number (with space delimited country code, region code and local number), an ISBN, a simple map/object made of two pairs, a GUID, a CRC32 checksum, an ISO-8601 zoned date/time, and an ISO-8601 duration. What more scalar types it can be extended with? Since there is no type for scalars in this "format" does not dictate types or preferred scalar formats letting the application make decision how to interpret these on its own.

> Commas makes numbers faster to interpret. Something `ls` is missing. As I stated on another branch English is the global lingua franca so commas every three digits is the standard.

For whom? Humans? Why would data encoding obey region number|date/time notation standards at all? English, but US, UK, Canada, or any other English-speaking country? You've been told that in that thread too, especially if spaces or underscores are even more readable for monospace fonts. You don't need it.

> See https://news.ycombinator.com/item?id=42049033

Funny enough -- your format saves on key/value pairs syntax appealing to 4 vs 6 overhead (okay, cool), but your array elements delimited with ``, and amazingly bad at keyboard typing ergonomics, loses to simple and regular JSON `,` syntax (3 vs 1 overhead). Isn't it blind or crazy?