Union with wildcard and number in Proposal A

[glyn]

Proposal A supports a mixture of wildcards and numbers such as $[*,1] whereas the consensus is "not supported".

What's the rationale for this behaviour of Proposal A? Should Proposal A change?

My personal preference is to go further and allow arbitrary mixtures of wildcards and numbers and produce the corresponding values in the output as that seems to make the syntax and semantics more uniform. For example, Goessner (here) allows the selector $[*,1,0,*] which, when applied to the input document:

["a","b","c"]

produces the output:

[
   "a",
   "b",
   "c",
   "b",
   "a",
   "a",
   "b",
   "c"
]

Admittedly, this behaviour is useless in practice, but it should makes the behaviour easier to understand (and document) as there are fewer special cases to remember.

[glyn]

BTW, the background to this is that I'm bumping regression_suite.yaml in my implementation and wondering whether to go with the consensus or do what I suggest above. If Proposal A is going to "fold" and go with the consensus, I'll probably do the same for ease of maintenance of the regression tests.

[glyn]

I wonder if part of the rationale is that Proposal A is free to extend the consensus in the sense that if the consensus on a given selector is NOT_SUPPORTED, Proposal A is free to support the selector any way it likes.

[remorhaz]

I vote with both hands for union of arbitrary matchers (numbers, identifiers, wildcards and filters) and for "extending consensus" principle. The union approach is powerful and intuitive.

[remorhaz]

Speaking about extending consensus - we should choose one of the following as the final goal of Proposal A:

1. Most implementations conform to the proposed standard without being changed (this position is against extending consensus).
2. Most queries supported by implementations conform to the proposed standard (this position allows extending consensus).

As for me I think that in current situation (lots of different implementation with no standard) position 2 is more reasonable.

[glyn]

Meta-comment: I think we could benefit from less structured discussion in addition to issues, so I've taken the liberty of creating a jsonpath-standard slack workspace. This invitation should work for 30 days.

[cburgmer]

I see a few things discussed here:

1. Why did the Proposal A include a wider interpretation of bracket notation?
2. Is it a good thing to allow more/all combinations in bracket notation?
3. How should the Proposal A (maybe any alternate Proposal) deal with the fact that it will deviate in the implementation on some, many or most other implementations ?

I'll try to answer 1. Let's continue to talk about 2. How about we discuss 3. in a new issue?

I didn't think about 3 at all, so thanks for bringing it up!