Applying filters to objects in Proposal A

[glyn]

The Goessner article and implementations conceive of filters as applying only to arrays. However, Proposal A allows filters to apply to (the values of) objects. The README does not explain the rationale for this decision, but it would be helpful to know.

I'm personally not convinced that this capability is beneficial:

• Filtering applies to the values of an object and not to its keys which seems somewhat arbitrary and asymmetric.
• The current consensus is that objects cannot be accessed using array indexing, which seems analagous to using a filter to access an object.

[cburgmer]

Thanks for bringing this up.

I would love to see this documented in the Proposal's README, let's see whether we can drive out some documentation here.

Now, to the issue at hand:

I have to admit that I haven't thought much of it maybe. For me the filter relates to $.* (https://cburgmer.github.io/json-path-comparison/results/dot_notation_with_wildcard_on_object.html) which has a consensus to iterate via values.

If you look at the implementation of Proposal_A, you'll see that the filter expression operator (https://github.com/cburgmer/json-path-comparison/blob/master/proposals/Proposal_A/operators.js#L131) makes use of the concept "All Children" which it shares with the recursive descent and of course the all children operator. The beauty here for me is that this identifies an internal smaller building block, and - using Ockham's razor as an argument - allows me to find a small yet powerful solution.

My argument not to apply the same generalisation to the array slice operator is that objects are not meant to express a certain order, and hence picking indices feels wrong. (I do have an opinion on a natural order of objects though, that I'll bring up in a different discussion :) )

One, and only one, counter argument so far towards including array slice in the same bucket, would be to equate $[:] and $.*. Currently, for arrays they behave the same in Proposal A, however for objects the first will return an empty list only.

As for your point about object keys: it seems no implementation that stays close to Goessner has implemented anything around addressing object keys in filters. Although we would have to dig into this a bit more to be sure maybe.

[cburgmer]

One thing I'm taking away for me here is that my guiding principle for Proposal A was to find the smallest implementation that offers a consistent solution to the consensus. Many of the outliers in the other implementations I feel are from the implementations applying unnecessarily complex rules that then allow for illegal states to be representable.

[glyn]

Thanks for laying out the rationale. It makes a lot of sense. I particularly agree with your point about array indexing (except for [:], which I don't think we should special case) being essentially non-deterministic and that's a great reason to avoid going down that road.

So I'm warming up to filtering objects. I wonder how much it would violate the principle of least surprise to someone familiar with older implementations starting to use Proposal A, but since this is effectively lifting a restriction, it's hard to see it breaking current usage very often. With good documentation, the new behaviour wouldn't be surprising at all. In fact it might then seem surprising that filtering objects hadn't always been supported.