A tree with properties indeed.

They vary in syntax and how they deal with scalars, objects and collections. Having to write 'myKey' is a bit unfortunate in json for example. Still, for any document larger than 20 lines yaml will fall apart easily.

Xml (dialects) mark the beginning and end of nodes explicitly, which deviates from json/yaml. Xml can represent nodes within the value, which is impossible for json/yaml. To convert such xml value to the latter, you have to break up such a node in fragments and represent them as a collection in json/yaml.

> Xml can represent nodes within the value, which is impossible for json/yaml. To convert such xml value to the latter, you have to break up such a node in fragments and represent them as a collection in json/yaml.

Are you talking about XML like `<text>Something something <para> inside </para> something else</text>`? I thought this would also presented as the text element having three children, the text "Something something", the <para> tag with its subtree, and the text "something else". Am I misremembering?

Exactly, that is the «breaking apart» I was talking about. Xml is the more natural way for humans to express that particular use case.

But my point is that an XML parser would still present that as three children, right?

It's just when writing the document that you get the advantage, the data model is the same.

Jup, it is human ergonomics, but a mismatch for your average programming data structure.

I think that is one reason why json took of for exchanging machine readable data, xml is too expressive, and leans towards document authoring.

Agreed, a lot of the features that make XML very nice for embedding tags in text documents make it very inefficient at expressing explicit tree data structures.

I doubt that, if I had my money on it I’d guess the main reason is var obj=JSON.parse(string) and its ease.

That is half the reason. JSON was limited to Javascript when SOAP/WSDL was king for data exchange. If I remember correctly, XML apis predates json in Javascript. IE5 and XML were really hot back then. xml.loadString() is equally simple.

Json got introduced because XMLHttpRequest was an IE-only component. Data exchange was done mostly between servers, back then the front-end was really dumb. Why xml got slowly replaced is because that for machine generated data, json proved to be sufficient. Any json library is easier to work with then their xml counterpart, exactly because of what we discuss here.

The complicated part is, that this tree has different types of nodes. Some support properties and child's, some not. So I would call it a chimera tree or mixed tree, or something like that.

For a query language, you can generalize to all nodes supporting all things. You will be able to write some queries that will never return results, at least in a given input data format. That does not seem so bad.

No it makes so much more sense to introduce nil and then constantly pepper your code with ? (Null-colasecing) Operators everywhere

(Looking at you, jq, though to be fair JSON itself supports null...)

Coincidentally, this is exactly what XPath and XQuery do. E.g. text nodes don't have children nor attributes, yet it is perfectly legal to do text()/foo or text()/@foo - and the result is an empty sequence.

If you want this kind of semantics with JSON, take a look at https://www.jsoniq.org