Interesting although this seems a little out of date because xml seems to one of the least desirable data formats for modern programming languages. Maybe this is more useful for legacy enterprise use cases that I don’t know about.
This is essentially a way to write grammars for things and get the ability to parse them as trees in a common format that is interchangeable with things like JSON.
I honestly don't see much of a difference between this, and something like a PEG grammar where you do this:
let parsed = peg.parse(input, grammar)
let xml = json2xml(parsed)Ultimately what all that means is that all e.g. json documents can be represented losslessly in xml, whereas the reverse is not true without explicit external schema. Which means targeting XML covers other less capable interchange formats implicitly.
There is a real advantage of XML over JSON not mentioned though, which is its usefulness in annotating computer-readable data into an otherwise human-editable document. There's not a lot of these cases, and where they're at you're probably still better off using AsciiDoc, Markdown or even HTML instead, but those use cases are out there and JSON is awful for those.
Yes, that's my point. If a human is required to look at the JSON it's not hard to find a parser that permits comments. So of course it would be supported if it was actually needed.
Even without that though, you can do something like the trick I used in a JSON-based format:
{ "__comment": "For help with this file, go to http://wiki.example.com/...", ... "foo": "..." }
That does have the problem that your programs processing the JSON need to strip out keys with that name if it would interfere with the program. So it's probably easier just to add the line of code in your parser saying to permit comments.
Meanwhile, XML comments have issues of their own, as you have to be familiar with SGML rules on how -- are handled to safely use or edit XML comments. So while they are nice to have it's not as if they have no nuance either.
Granted, JSON has achieved this same level of universality, but everything else (excepting perhaps CSV files) either suffers from obscurity or from weak/ambiguous/competing specifications.
The dream of semantically rich documents that XML provides (like, say, being able to cleanly interweave MathML, SVG, and XHTML in one document) is unmatched.
I think we'd see a lot more XML usage if it hasn't been over-promised, over-delivered (WS-*), and over-used (enterprise Java). If XML had stuck to its lane (making a schema language like RelaxNG instead of XmlSchema, for one thing) it wouldn't have left such a bad taste in so many people's mouths.
Oh, here: https://www.rfc-editor.org/rfc/rfc8785
No duplicates, no whitespace, sort the keys, copy number serialization from javascript, a couple other little details.
This only two years old while JSON is in common usage for more than a decade... Without a spec there's dozen way to achieve it, for example by sorting keys using UTF-8 instead of UTF-16 values like done in this document, and the slightest difference would break things when used with crypto.
Now, there is a trade off in more complex paths to interoperability with Uncle Joe and his DTD. It is still easier than trying to parse some convoluted json coming from yet another api that the dev team never dogfed a day in their life - because you can jump levels so precisely in xpath due to those verbose types and attributes. So as to XML verbosity at least, which for many appears to be the main complaint, for me it is worth it when done right.