cabo
commented
1 year ago JSON "permits" duplicate member names as much as my car "permits" crashing it into a tree.
As this "feature" of JSON is already marked as non-interoperable, I do not believe JSONPath needs to provide an interoperable behavior for this case. Much of the non-interoperability comes from the underlying libraries treating the car crash in different ways, and there is no sensible way in which a JSONPath implementation could be deterministic without supplying its own implementations of these libraries. That would essentially fork JSON.
This issue was raised on the JSONPath mailing list by Michael Brooks. It is reproduced here for better visibility. The issue relates to draft 7. I have broken the original paragraph into four to aid readability.
Unpredictable behaviour for duplicate sibling names (see 3.1). Although RFC8259 validly discusses the unpredictability of software implementations when parsing duplicate sibling names, that is merely a discussion of implementation issues - it has no bearing on the standard itself which permits duplicate sibling names, and parsers exist which happily support them (I have written one myself).
Consequently it is not acceptable for JSONPath to fail to provide for node sets arising from the selection of duplicate sibling names.
XPath was able to cleanly handle node sets without discriminating names because the specification of XML does not incorporate any form of array and therefore square bracket notation ([]) could be used to select from such node sets without ambiguity. JSONPath is not so fortunate - the array is a valid type in JSON and square brackets are already in use within JSONPath as array index selectors. It is therefore understandable that anyone engaged in an attempt to standardise JSONPath would prefer to avoid addressing this issue, but ultimately such avoidance is indefensible - JSON permits duplicate sibling names and consequently for a JSON query mechanism to be taken seriously it must provide a scheme for handling this.
Furthermore, as stated in 5.2, unpredictable behaviour has the potential to lead to a security vulnerability. I do not contend that a mechanism is necessarily needed by which to select from a node set, but at the very least the standard would need to mitigate the "unpredictable" behaviour by stating that any encounter with duplicate sibling names will (or at least may, if we wish to leave this up to implementors) result in a node set that is the union of their values.