TER is irrelevant. The Internet has shown the advantages of text formats at the high level, e.g. email and the web.
10 karma · joined December 25, 2022
Response to graph conjecture stated https://news.ycombinator.com/item?id=42072133.
As terse as ᴊꜱᴏɴ.
It is a tidier solution.
> I still can't get what makes timestamps (and GUIDs) so special so that they have special sections in your document.
They are common in data.
> [...] boolean attributes
Separate attributes and sub elements is a mistake. One should be able to guess an ᴀᴘɪ.
> What more scalar types it can be extended with?
> letting the application make decision how to interpret these on its own.
That is laborours! A Xᴇɴᴏɴ library provides AsGuid, AsDateTime etc.. and serialization directly to/from those types.
>For whom? Humans?
Yes. Human have to read markup.
> Why would data encoding obey region number|date/time notation standards at all? English, but US, UK, Canada, or any other English-speaking country?
I repeat! READABILITY.
> Isn't it blind or crazy?
No, quite the opposite.
• Terse.
Xᴇɴᴏɴ is as terse as ᴊꜱᴏɴ using 3 characters per scalar value <key=value> rather than ”key”:value, (4) or ”key”:”value”, (6). Xᴇɴᴏɴ is significantly more terse than xᴍʟ <key>value</key> (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 <Person> or <Example-Document>
> I can't see how different is that comparing to XML or JSON that semantically "have graph support" just because they also can declare something considered ids and references to the identified element.
When serialising data with ᴊꜱᴏɴ one has to use special field names such as $id; hoping the programming language does not. It DOES have native graph support that xᴍʟ and ᴊꜱᴏɴ do not.
> # [..] it may be a comment start
No.
> but what interoperability is all that about?
Interoperability between implementations. If you were using Xᴇɴᴏɴ to communicate between two different languages, say the C# and a Python implementation, agreeing of what an integer IS is helpful. Both Xᴇɴᴏɴ libraries can provide support for encoding say ɢᴜɪᴅs. You have missed the point. A user is always free to encode data as arbitrary strings.
> commas [...] readability." is just hilarious. Why should?
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.
> ∞ is allowed, but no mention on +Inf and -Inf, can be 4.2957×10^24 ∞ is +Inf. 4.2957×10^24 is not the xᴇɴᴏɴ standard.
>> It is more terse than ᴊꜱᴏɴ.
>Sorry, it's not.
See https://news.ycombinator.com/item?id=42049033
<<Timestamps>2026-09-24T16\:45\:22.5383742<&>2026-10-04T18\:25\:12Z<&>2026-04-02<$>>
Better than ᴊꜱᴏɴ which does not do timestamps.
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.
Having both begin and terminate arrays start with << is more consistent.
> `<>` and `<&>` (`{` and `}`?).
Using `{` and `}` would lead to more special characters.
> Auto-removing whitespaces may hurt.
It does not.
> Graphs... But what does graphs make first-class citizens here and why?
It is simpler to support graphs in the markup. The fact is that the data being serialized may be structured in a graph.
> CR/LF
It supports LF only ᴜɴɪx line ends as well as CR/LF internet line endings.
> Comments [...] To be honest, I can't recall any instance I could see the percent sign elsewhere for this purpose
LaTex and PostScript both use % for comments. # matches the usage in ᴄꜱꜱ and ʜᴛᴍʟ, relating to an id/page location.
> What if the comments would start with a well-known `#` at least with a space right after it so that it wouldn't be considered a "graph id"
Having a space after the # differentiate between and id and comment would be a mistake.
> Scalars. Crazy [...] UUIDs
The Formats section is to facilitate interoperability between implementations, e.g. if you are encoding a ɢᴜɪᴅ [easy to say] then format it this way.
> not make it efficient in typing.
It is more terse than ᴊꜱᴏɴ.
> XML "v2" ... first-class array support
Xᴇɴᴏɴ has first class array support, the xᴍʟ like syntax leads to the <empty-arrray$$> notation.
> P.S. How does it look like in the document it marks up is minified (e.g., no whitespaces)?
Good.
Readability.
>I was asking why that particular variant [of Base64] was used.
I repeat, we are using the ʀꜰᴄ 4648 variant.
> [separate standards documents] do you think that's also a no-go? Yes.
Data model here:
document := named-entity
named-entity := named-object | named-array | named-scalar
named-object := NamedObject(name, object)
named-array := NamedArray(name, array)
named-scalar := NamedScalar(name, scalar)
object := Object(id?, type?, field*)
array := Array(id?, type?, item*)
scalar := Scalar(id?, type?, value)
field := named-entity
item := object | array | scalar
name := CHAR+
id := CHAR+
type := CHAR+
value := CHAR*
I evaluated xᴍʟ 1.0 and 1.1’s restrictions but consider the alternative, accepting anything but the empty string to be simpler.
>A lot of English-speaking countries actually have `.` and `,` swapped:
Which?
>...should state that encoders should pick a long enough decimal representation to avoid any such issue.
.net for example has round trip encoding to achieve this.
> Which base64 standard in [1]?
As linked in the document, we refer to ʀꜰᴄ 4648 for Base64 using the simplest version which states that “Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise”.
> I have outlined my rationale for layering in other comments.
>> Graph is generally a bad thing to encode at this level
The ᴅᴏꜱ attach you are concern about is not applicable. Layering graphs on top of the encoding in a separate standard is not practical. As stated serialization requires a graph structure.
>It is not too hard to define a data model in prose rather than code.
I have done that.
>May have been true in the past, but it's no longer true since SIMD-based parsers. Also the very existence of escape sequence prevents the true non-destructive zero-copy (aka in-situ) parsing anyway. With such sequences, zero-copy/in-situ parsing has to be destructive to be performant and that can preclude some use cases. Allowing additional space characters is much easier than that.
SMID based parsers would almost certainly run faster with simplified byte handling rules. Practically, when say skipping whitespace, searching for two specific bytes is faster than the alternatives. Most strings do not have escape sequences so do not need to be copied, a scan for '\' is fast.
> `<<Name>...<<$>`
This is to be terse. An array type in an xᴍʟ like language is a leap forward. Additional significant characters would over complicate the standard.
- Commas are for readability as per English.
- Three digits are recommended for the encoder.
- Textual data is decoded into binary information in software so setting expectations, e.g. supporting ∞, facilitates interoperability by reducing impedance mismatches.
- If the implementation uses ɪᴇᴇᴇ doubles the rounding shall be as expected.
- Unicode surrogates are disallowed.
- We are following the Base64 standard exactly.
- It is essential for data to be structured as a graph, it simply occurs. Serialization on most data formats has the required support for graphs awkwardly layered on top of the encoding.
- The C# implementation defines the data model; essentially objects, array and scalars with multiple parents for nodes. The Formats section is to, as stated, facilitate interoperability.
- Limiting whitespace to spaces and tabs does speed processing. The ᴜᴛꜰ-8 bytes can be left in the input buffer rather than copied. All significant bytes are ᴀꜱᴄɪɪ.
- There are no unmatched angle brackets (that was a typo).
- I know the reasoning behind XML.