i dont understand how it's "terse"? like, terse compared to XML alone?
See https://news.ycombinator.com/item?id=42049033
As terse as ᴊꜱᴏɴ.
New better alterative to XML, JSON and YAML
101–110 of 148 posts
Re: New better alterative to XML, JSON and YAML
#102Earlier quoted context omitted.
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.
I mean it can be encoded inline, including using \n in strings
Re: New better alterative to XML, JSON and YAML
#103Earlier quoted context omitted.
That is hard to believe, the data being serialized may always have a graph structure.
"May", not "should", so some data don't have a graph structure. It really boils down to the ratio between non-graph data and graph data. I have some reason to believe that the former far outnumbers the latter, but maybe you have some concrete evidences against?
You misunderstand. Given that data MAY be a graph structure, the markup MUST support that. A tree with pointers to the parent nodes has a graph structure, a common enough occurrence.
Re: New better alterative to XML, JSON and YAML
#104Earlier quoted context omitted.
Thanks for writing this up! Sounds like you really dig deeply in to this. Not entirely sure what you mean with canonical representation (I've heard this in the context of JSON-LD before, though). Can you explain what you mean here? Where do you see the problem with Graphs and Dos? A reference is just a pointer. You just have to be careful when doing recursive code. I actually like the idea to explicitly define how a…
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…
Is canonilization not irrelevant. Any format with comments is not canonical; so xᴍʟ is not, ᴊꜱᴏɴ has escapes options for string characters so it not either.
Response to graph conjecture stated https://news.ycombinator.com/item?id=42072133.
Re: New better alterative to XML, JSON and YAML
#105Earlier quoted context omitted.
It is more terse than JSON.
Have you created any benchmarks to demonstrate this?
Re: New better alterative to XML, JSON and YAML
#106Earlier quoted context omitted.
The “readable indented text” refers to https://xenondata.org/#scalars where multiple lines of text can be indented and extracted as expected. One can argue that JSON is not readable due to requiring escaping (\n) for multiple line strings.
This is not enough of an improvement over JSON to justify choosing another format, given that the new format is (A) not recognized and (B) uses even more special characters. (By "not recognized" I actually mean there are no implementations given for any languages, much less accepted standard implementations.)
Re: New better alterative to XML, JSON and YAML
#107This is not better than XML or JSON. Anything is better than YAML, but this is not great.
Make a point
Re: New better alterative to XML, JSON and YAML
#108I 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…
TER is irrelevant. The Internet has shown the advantages of text formats at the high level, e.g. email and the web.
Re: New better alterative to XML, JSON and YAML
#109"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.
I am futureproofing.
Re: New better alterative to XML, JSON and YAML
#110Earlier quoted context omitted.
The example you give is valid xᴇɴᴏɴ. The key and value may contain whitespace and must be delineated? s are that that made XML and HTML good.
There is a widespread agreement that XML is generally bad for the data serialization, while HTML is not much questioned as such. You can't carelessly adopt angle brackets without why such difference exists in the first place [1]. [1] Hint: "semi-structured data"
You mean ʜᴛᴍʟ is not used a such.