Q: Should boolean literal be accepted (or rejected) in 3.5.8. Filter Selector

[cyrilMargaria]

The filter selector is defined as

filter-selector    = "[" S filter S "]"
filter             = "?" S boolean-expr

Filter like [?(1==1)] or [?(1==2)] are valid, [?(true)] or [?(false)] are logically equivalent but currently rejected.

Is the intention to have true or false rejected or should the specification allow them? Having explicit text could be helpful. This could be done for instance by using:

basic-expr        = exist-expr /
                    paren-expr /
                    relation-expr / true / false

[goessner]

... sounds reasonable to have the constants included. I suggest as slight simplification of above:

basic-expr  = exist-expr /
              paren-expr /
              comp-expr / 
              regex-expr /
              true /
              false

making relation-expr obsolete. Any objections here?

[cabo]

The filter selector is defined as

filter-selector    = "[" S filter S "]"
filter             = "?" S boolean-expr

Filter like [?(1==1)] or [?(1==2)] are valid, [?(true)] or [?(false)] are logically equivalent but currently rejected.

Correct.

Is the intention to have true or false rejected or should the specification allow them?

The specification currently is very frugal in what is supported. We can't even add! (See Table 5 for an overview.)

Having explicit text could be helpful.

The ABNF is quite explicit about that.

This could be done for instance by using:

basic-expr        = exist-expr /
                    paren-expr /
                    relation-expr / true / false

We could, but can you explain what would be achieved by this?

I'd probably add

@.price + @.tax < 20

before true and false in tautological positions.

I'm not writing this to push back, but in an attempt to determine the proper boundaries for the expression language.

Grüße, Carsten

[goessner]

hmm ... from my point of view true and false simply are the most basic boolean expressions - basic-expr. So they have significance here ... regardless of meaningful benefit. I can even imagine to use them for testing filters instead of having to write 1==1 or true == true which is allowed btw.

[cyrilMargaria]

As described by Stefan, tautological are the most basic boolean expressions. The benefit is that it makes easier to troubleshoot expressions while retaining the filter part as applies not only to [?(true)] but also to [?((@.price < 50) && (true))]

MfG, Cyril

[glyn]

I've used this kind of thing in troubleshooting in other contexts, but [?((@.price < 50) && (true))] is equivalent to [?((@.price < 50))]. Did you mean [?@.price < 50 || true]? (unnecessary parentheses removed)

[glyn]

There is no consensus among implementations for $[?(true)] or $[?(false)].

[danielaparker]

A question for @goessner.

In Goessner Javascript JsonPath, given the document (from the JSONPath Comparisons)

[1, 3, "nice", true, null, false, {}, [], -1, 0, ""]

and selector

$[?(false)]

the result is false, indicating no matches, which I understand.

But for selector

$[?(true)]

the result is

[1, 3, "nice", true, null, false, {}, [], -1]

which I don't understand, I don't understand why the last two items in the array were not selected. Why is it doing that, what rules is it following that would produce that result?

The only way I can explain it is if Goessner Javascript JsonPath is substituting true with @ in the selector, but why would it do that?

In the JSONPath Comparisons, all other implementations that returned a non empty result returned every item in the original array.

[gregsdennis]

On the recent call, we determined that true and false are fine for use as JSON literals (e.g. for comparisons like [?(@.foo == true)]), but it doesn't make sense to use them as boolean values (e.g. as shown in the OP). We couldn't find a compelling use case to support this outside debugging an expression.

[goessner]

Yes, it's true, that we couldn't find an use case for true and false beside expression debugging.

[goessner]

@danielaparker:

Since I pragmatically reused the JavaScript engine for expression evaluation, I can explain the result above only by the idea, that during iteration over array elements every item is converted to Boolean and then compared against true. This doesn't match the last 2 elements according to JavaScript rules.

As we do not allow type conversion, this result does not conform to JSONPath.

[danielaparker]

@danielaparker:

Since I pragmatically reused the JavaScript engine for expression evaluation, I can explain the result above only by the idea, that during iteration over array elements every item is converted to Boolean and then compared against true. This doesn't match the last 2 elements according to JavaScript rules.

Thanks, appreciated.