Should we provide for structured types in containable?

[cabo]

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/125#discussion_r721614374

[goessner]

After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward:

Two structured types are equal, if they are equal on a per-node basis.

also see The Abstract Equality Comparison Algorithm ... not exactly, what we want though.

We need to be clear about order ... !

[1,2] == [1,2]
{x:1,y:2} == {x:1,y:2}
[1,2] == [2,1]  // ?
{x:1,y:2} == {y:2,x:1} // ?
[] == []
{} == {}

Containables may be defined on exactly that comparison rule.

I believe, we need to add objects here again. Also we need to discuss subsets.

Array Examples:

1 in [1,2,3]             // primitive value lhs
[1,2] in [1,2,3]         // structured value lhs
[1,2] in [1,2,3,[1,2]] // subset
[] in [1,2,3]             // empty array
[] in [1,2,3,[]]          // empty array
{} in [1,2,3,{}]          // empty object
{x:1,y:2} in [{x:1,y:2}]

Object Examples:

'x' in {x:1,y:2}
['x','y'] in {x:1,y:2}
{x:1} in {x:1,y:2}
{z:3,x:1} in {x:1,y:2,z:3}
{} in  {x:1,y:2}

Once having agreement about handling that edge cases (maybe there are more), we might add it to the spec.

Btw.: JavaScript resolves all comparisons above to false, since objects are equal only, if they are referencing the same object (no deep equals).

[glyn]

Comments inline.

On Tue, 2 Nov 2021 at 11:48, Stefan Goessner @.***> wrote:

After thinking a while about comparing structured types, I now see no problem to support equality of them. I agree to handling them is straightforward:

Two structured types are equal, if they are equal on a per-node basis.

also see The Abstract Equality Comparison Algorithm https://262.ecma-international.org/5.1/#sec-11.9.3 ... not exactly, what we want though.

We need to be clear about order ... !

[1,2] == [1,2] {x:1,y:2} == {x:1,y:2} [1,2] == [2,1] // ?

No. Arrays are ordered and equality tests should respect that ordering.

{x:1,y:2} == {y:2,x:1} // ?

Yes. Objects are unordered and equality tests should respect that lack of ordering.

[] == [] {} == {}

Containables may be defined on exactly that comparison rule.

I believe, we need to add objects here again. Also we need to discuss subsets. Array Examples:

1 in [1,2,3] // primitive value lhs [1,2] in [1,2,3] // structured value lhs

No. Conflating membership and subset violates the principle of least surprise and so is likely to cause confusion. Also I am not aware of any precedent for such conflation in mathematics or programming language semantics.

[1,2] in [1,2,3,[1,2]] // subset

This doesn't add any value beyond the previous case. Better to discuss:

[1,2] in [[1,2]] // structured value membership

Also, we need to discuss ordering of arrays. For example:

[1,2] in [[2,1]]

should be false, if we agree that [1,2] != [2,1].

[] in [1,2,3] // empty array [] in [1,2,3,[]] // empty array {} in [1,2,3,{}] // empty object {x:1,y:2} in [{x:1,y:2}]

Object Examples:

I don't think we should conflate membership and subset. Since "in" has a stronger connotation of membership than subset, I don't think we can easily define "in" with an object on the right hand side. Note also that there isn't yet a notation for a mathematical "maplet", but if we represented it as a pair, e.g. ('x',1), then we could test membership of objects thus:

('x',1) in {x:1}

(However, I don't think this is worth the cost of increased complexity of the spec.)

'x' in {x:1,y:2} ['x','y'] in {x:1,y:2} {x:1} in {x:1,y:2} {z:3,x:1} in {x:1,y:2,z:3} {} in {x:1,y:2}

Once having agreement about handling that edge cases (maybe there are more), we might add it to the spec.

Btw.: JavaScript resolves all comparisons above to false, since objects are equal only, if they are referencing the same object (no deep equals).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/127#issuecomment-957364968, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAXF2J2TDFR5P3LGOZ4QH3UJ7FX3ANCNFSM5GVV2MMA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[goessner]

I totally support a decision to:

• not dealing with subsets
• restrict the rhs to arrays only

with contain-expr's.

[cabo]

We decided not to have " in ", so this is now closed/revisit-after-base-done.

[gregsdennis]

I've supported this with configuration. You can play with it at https://json-everything.net/json-path.