Support equality/inequality tests of structured values

[glyn]

The current spec's approach of equality comparisons of structured values always yielding false (and inequality always yielding true) has some downsides:

• it is likely to surprise users
• it would be difficult to change the behaviour in future without damaging interoperation

So I propose that we support equality/inequality tests of structured values.

Out of scope for this issue:

• introducing literal structured values - these can be introduced later if necessary,
• ordered comparisons of structured values - these are less likely to be useful and the current spec's approach of these comparisons always yielding false seems reasonable.

This issue follows on from https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/213.

Note: the current spec includes the comment:

<!-- issue: comparison with structured value -->

[gregsdennis]

(out of scope) ordered comparisons of structured values

Why? Arrays need to be order-checked because they are inherently ordered.

[glyn]

(out of scope) ordered comparisons of structured values

Why? Arrays need to be order-checked because they are inherently ordered.

Because I am trying to focus on changing the WG consensus on == comparisons of structured values. If this is successful, I'd be happy to consider addressing the above feature. But I'd like to rule it out of scope for now so we focus on what I think is a fairly simple improvement.

[gregsdennis]

I agree with your sentiment, but I don't think that equality of arrays can be separated from ordering. JSON explicitly states that arrays are ordered, and we need to respect that.

An array is an ordered sequence of zero or more values. - RFC 7159, Section 1, last sentence (also present in RFC 8259)

Additionally, starting with accepting [1,2] == [2,1] then coming back and saying that they're not because of ordering is awkward

[glyn]

@gregsdennis I think there may be a misunderstanding. I agree that == comparisons of arrays should be ordered in the sense that corresponding elements must be compared for equality. That's hopefully clear in https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/237 which says:

equal arrays, that is arrays of the same length where each element of the first array yields true when compared using == to the corresponding element of the second array,

With that definition, [1,2] == [2,1] yields false.

My out of scope feature "ordered comparisons of structured values" was meant to cover comparisons between structured values using the operators <, <=, >, and >= (like $.arr1 < @.arr2 and $.obj1 < $.obj2). I think there's a reasonable case to be made for such comparisons of arrays, but I'd like to defer it until we've got consensus on == and !=.

[glyn]

Also out of scope for this issue:

• making a <= b yield true if and only if a==b or a < b yield true for all a and b of the same type,
• making a >= b yield true if and only if a==b or a > b yield true for all a and b of the same type.

[glyn]

Also out of scope for this issue:

• equality comparison of objects with non-unique names (see https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/237#issuecomment-1211904334)