5 ms·

Is it anything else than a tree with properties for each node? I think you could well apply jsonpath to yaml, except for the different data types, which is wha

Is it anything else than a tree with properties for each node? I think you could well apply jsonpath to yaml, except for the different data types, which is what makes you need xmlpath, jsonpath, file path, css and so on. If you're willing to do some automagic conversions, you could probably do that right now, if you write the code for it.

exceptione 2y ago
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.
- tsimionescu 2y ago
  > 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?
  - exceptione 2y ago
    Exactly, that is the «breaking apart» I was talking about. Xml is the more natural way for humans to express that particular use case.
    - tsimionescu 2y ago
      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.
      - exceptione 2y ago
        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.
        tsimionescu 2y ago
        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.
        rileymat2 2y ago
        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.
        exceptione 2y ago
        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.
PurpleRamen 2y ago
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.
- lucianbr 2y ago
  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.
  - hughesjj 2y ago
    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...)
  - int_19h 2y ago
    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 https://www.jsoniq.org

exceptione 2y ago

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.

tsimionescu 2y ago
> 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?
- exceptione 2y ago
  Exactly, that is the «breaking apart» I was talking about. Xml is the more natural way for humans to express that particular use case.
  - tsimionescu 2y ago
    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.
    - exceptione 2y ago
      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.
      - tsimionescu 2y ago
        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.
      - rileymat2 2y ago
        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.
        exceptione 2y ago
        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.

PurpleRamen 2y ago

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.

lucianbr 2y ago
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.
- hughesjj 2y ago
  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...)
- int_19h 2y ago
  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 https://www.jsoniq.org