Double quotes around literal values not rejected but do not match.

[elyobo]

The literal expressions and raw string literals sections of the specification permit literals to be delimited by backticks or single quotes, but jmespath.php is partially allowing double quotes as well; no parse error is returned, but matching doesn't take place. This behaviour is possibly confusing for users that incorrectly try to use double quotes; a parse error, ideally indicating that they should use single quotes or backticks, would be more informative.

// Expected: parse error
// Actual: []
JMESPath\search('[?foo == "bar"]', [['foo' => 'bar']])

[elyobo]

This behaviour is the same in https://github.com/jmespath/jmespath.rb, so it's possible that the compliance tests don't cover this behaviour.

[mtdowling]

Double quotes are reserved for selecting elements from an object that may contain special characters. For example, if I have a json document {"foo.bar": "baz"} and I wanted the value of "foo.bar", then I would need to place "foo.bar" in double quotes to prevent JMESPath from treating the "." as a subexpression. So given the expression "foo.bar", JMESPath will return "baz".

Raw string literals only work with single quotes -- e.g., 'foo.bar' will create the literal value of a string containing "foo.bar".

Backticks are used to encapsulate valid JSON documents. Passing unquoted strings in backticks is deprecated in favor of using raw string literals.

[elyobo]

Ah, I see, so in my example the double quotes are valid but redundant as there is no ambiguity with a field named bar anyway. JMESPath tries to match the field foo against the field bar, but as there is no bar the match fails and no result is returned.

# This does match, because "bar" is equivalent to field bar (no quotes), which matches
JMESPath\search('[?foo == "bar"]', [['foo' => 'bar', 'bar' => 'bar']]);

Thanks for the explanation.