Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New better alterative to XML, JSON and YAML

xenondata.org

Post reply on HN
Print view View original

81–90 of 148 posts

Re: New better alterative to XML, JSON and YAML

#81

Post by GeneThomas »

lifthrasiir wrote: post #44
cirwin wrote: post #19

Funnily enough, I've been working on solving the same problem concurrently. Though in my _very_ biased opinion; I think CONL is easier to read and write: https://github.com/ConradIrwin/conl value = example map a = b list = 1 = 2 multiline_value = """bash #!/usr/bin/bash echo "hello world"

Agreed that this is much better than the OP. That said, my general opinion is that a whitespace-only indentation should be avoided especially in the serialization format due to the inherent ambiguity of whitespace characters and resulting human mistakes. When I designed CSON [1] I strived to make it as readable as possible without the indentation for that reason. [1] https://github.com/lifthrasiir/cson

Indentation in xᴇɴᴏɴ is optional and for readability.

Re: New better alterative to XML, JSON and YAML

#82

Post by GeneThomas »

lifthrasiir wrote: post #66
zzo38computer wrote: post #62

Earlier quoted context omitted.

> I believe there is no other feasible encoding than UTF-8 for textual formats now. I disagree, although I do not believe that this disagreement should have to affect some file formats, since some file formats should not need to care about the character encoding, except perhaps specific details, e.g. that ASCII bytes have ASCII meaning and non-ASCII bytes have non-ASCII meaning (which is true of UTF-8 and of some oth…

> I disagree, although I do not believe that this disagreement should have to affect some file formats, [...] Ah, if you just want to make the UTF-8 requirement less strict for simpler decoders, that can be actually okay. My belief is more about legacy encodings like Shift_JIS. I never seriously tried to fit any graph struture into a serialization format, so I don't yet have a very concrete opinion besides from what…

That is hard to believe, the data being serialized may always have a graph structure.

Re: New better alterative to XML, JSON and YAML

#84

Post by GeneThomas »

TZubiri wrote: post #41

If this is not parody, try to be humbler and not claim to be better than the most popular solutions. It's unlikely, and even if you are right, we won't switch standards, best you can hope is individual adoption, and you can achieve that by offering a tradeoff, improving in one area.

It IS more terse than ᴊꜱᴏɴ and xᴍʟ and has many compelling features.

Re: New better alterative to XML, JSON and YAML

#85

Post by GeneThomas »

racingmars wrote: post #63

"Documents must be utf-8 and should have a byte order mark." No. If you're using UTF-8 (which is a good choice), the use of a BOM should be discouraged. Given that the format specification says documents MUST be UTF-8, there is no need to enable detection of UTF-8 content with the UTF-8 BOM. And, of course, the original purpose of the BOM (detecting big- or little-endian encoding) is unnecessary in UTF-8. The Unicode…

There exists a charset that is more efficient than UTF-8.

Re: New better alterative to XML, JSON and YAML

#86

Post by TZubiri »

GeneThomas wrote: post #84
TZubiri wrote: post #41

If this is not parody, try to be humbler and not claim to be better than the most popular solutions. It's unlikely, and even if you are right, we won't switch standards, best you can hope is individual adoption, and you can achieve that by offering a tradeoff, improving in one area.

It IS more terse than ᴊꜱᴏɴ and xᴍʟ and has many compelling features.

Ok that's good but capitalize TERSE instead of IS. That way you acknowledge that terseness is one of many parameters of a string data structure instead of focusing on our disbelief of its terseness.

Re: New better alterative to XML, JSON and YAML

#87

Post by GeneThomas »

tripple6 wrote: post #68

Sorry but I would never use this format for both manual or programmatic approach. * I've tried to read the data this format describes without reading its documentation and I just failed: the format is amazingly counter-intuitive. I never had a readability and understanding issues with XML/HTML, JSON or even YAML (that I think is overly complicated) when I saw them for the first time. * Terse does not mean cryptic. Ba…

> `` but not `>`

Having both begin and terminate arrays start with > `` 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 notation.

> P.S. How does it look like in the document it marks up is minified (e.g., no whitespaces)?

Good.

Re: New better alterative to XML, JSON and YAML

#88

Post by GeneThomas »

TZubiri wrote: post #86
GeneThomas wrote: post #84

Earlier quoted context omitted.

It IS more terse than ᴊꜱᴏɴ and xᴍʟ and has many compelling features.

Ok that's good but capitalize TERSE instead of IS. That way you acknowledge that terseness is one of many parameters of a string data structure instead of focusing on our disbelief of its terseness.

A basic scalar pair in ᴊꜱᴏɴ is "key":"value", or "key":value, so a 4 or 6 character overhead. xᴇɴᴏɴ is , 3 characters. In my tests xᴇɴᴏɴ IS more terse.

Re: New better alterative to XML, JSON and YAML

#89

Post by zahlman »

GeneThomas wrote: post #80
zahlman wrote: post #31

Earlier quoted context omitted.

` ` is not simpler than `}`, nor `]`. The array syntax has the "extra open (angle) brackets": in ` Fredrick Freddy ` we see ` `.

It is more terse than JSON.

Have you created any benchmarks to demonstrate this?

Re: New better alterative to XML, JSON and YAML

#90

Post by lifthrasiir »

GeneThomas wrote: post #79
lifthrasiir wrote: post #70

Earlier quoted context omitted.

> Which? Oh, I just realized that I carelessly put "English-speaking" there. (AFAIK the exact reversal does exist in English, but is much rarer and not entirely domestic.) But that doesn't really justify the use of comma in numbers. > .net for example has round trip encoding to achieve this. That was never guaranteed to my knowledge, and there also seems an apparent difference in .NET Framework and .NET Core/Runtime…

>But that doesn't really justify the use of comma in numbers. 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 := NamedAr…

> Readability.

Okay, I see you demand a very explicit question: why did you use comma instead of other characters for grouping?

> [separate standards documents] do you think that's also a no-go? Yes.

I like to hear why then, given this approach seems to be very successful for Unicode and many others.

> Data model here:

Thank you for the grammar. The document will massively benefit from such explicit description, I completely missed an unnamed scalar for example (because it has no syntax at all). The grammer doesn't have to be reproduced at all, for example the following is my attempt to rephrase it in prose:

There are three kinds of entities in Xenon: objects, arrays and scalars. All entities may optionally have a name, a type, an ID or any combination of them. Objects can contain named entities or fields, where field names should be distinct within the same object. Arrays can contain either named or unnamed entities. Scalars can contain zero or more characters. Names and types are non-empty free-form strings and no meanings are assigned for them, but this document gives a guideline for common types to ensure the interoperability. IDs should be distinct within the same document, but otherwise they are only used to encode a graph structure and have no other meaning. Objects and arrays can contain a reference which can stand in for any entity with given ID; references in an object needs its own name which can differ from the referent.

Please consider a similar clarification early in the document.

Post reply on HN