RFC 9535: Scalar array element comparison fails

[fubar-coder]

What is the current bug behavior?

I encountered non-working JSON path queries:

$[?@ != '8f34e5ec-d698-4f17-a70a-28e944ee0075']

and

$[?(@ != '8f34e5ec-d698-4f17-a70a-28e944ee0075')]

Both should - according to RFC 9535 - work.

Steps to reproduce

This is the test document:

[
  "efba2bf3-e6e8-4a93-948e-7b83b3ddc375",
  "8f34e5ec-d698-4f17-a70a-28e944ee0075"
]

What is the expected correct behavior?

The correct behavior should be that the following capture should set the variable (item_id) to efba2bf3-e6e8-4a93-948e-7b83b3ddc375.

item_id: jsonpath "$[?(@ != '8f34e5ec-d698-4f17-a70a-28e944ee0075')]" first

According to RFC 9535, this should work, as can be seen in the BNF "comparable" -> "singular-query" -> "rel-singular-query" -> "current-node-identifier"

The "singular-query-segments" has an asterisk around its whole definition, which means that "singular-query-segments" is effectively optional.

Execution context

I use the docker image (Linux).

• Hurl Version (hurl --version):

Probably 7.1.0, as I use the image tagged "latest".

Possible fixes

[jcamiel]

Hi @fubar-coder

With Hurl next version (8.0.0) we've completely revamped our JSONPath engine, to fully support RFC-9535.

Would it be possible for you to test it to see if it adresses your needs?

• you need a Rust build toolchain
• then cloning our repo git clone https://github.com/Orange-OpenSource/hurl.git
• then build cargo build and the Hurl binary is in target/debug
  (more information on how to build for your platform here => https://hurl.dev/docs/installation.html#building-from-sources)

Thanks 🙏

[BillionClaw]

Investigating the RFC 9535 scalar array element comparison issue. Will submit a fix.