This answer will be a bit convoluted but hopefully has some interesting and related concepts ... First, from [1]: ... two representative [JSON] transformation

This answer will be a bit convoluted but hopefully has some interesting and related concepts ... First, from [1]: ... two representative [JSON] transformation tasks are considered ... The exercise demonstrates that the absence of parent or ancestor axes in the native representation of JSON means that the transformation task needs to be approached in a very different way. The article shows that the ability to "navigate upward" to the parent of a node can make certain queries and transformation easier to implement. BTW, as far as I can tell, JSONIq does not provide a way to "navigate upward" ... But! also from [1]: The ability to navigate upwards (and to a lesser extent, sideways, to preceding and following siblings) clearly has advantages and disadvantages. Without upwards navigation, a transformation process that operates primarily as a recursive tree walk cannot discover the context of leaf nodes (for example, when processing a price, what product does it relate to?), so this information needs to be passed down in the form of parameters. However, the convenience of being able to determine the context of a node comes at a significant price. I remember dealing with trees in pure functional languages and finding that typically implementing parent pointers can be tricky [2]. I think if we combine this two facts, we can see that not all languages make the same query or transformation tasks equally easy. 1: Page 167 of https://archive.xmlprague.cz/2016/files/xmlprague-2016-proceedings.pdf https://archive.xmlprague.cz/2016/files/xmlprague-2016-proce... 2: https://okmij.org/ftp/Scheme/xml.html#parent-ptr https://okmij.org/ftp/Scheme/xml.html#parent-ptr