Alignment with spec in its current state (a report) about json-path-comparison HOT 7 OPEN

Looks like some new tests were added, including some spec-invalid cases. I've updated the set above to include the new invalid ones.

from json-path-comparison.

I've recently updated my implementation (JsonPath.Net) to conform with the spec. I haven't published it yet, but I wanted to share a finding.

These tests are not in alignment with the spec.

That reflects the fact that the IETF spec is incompatible in important ways with all existing implementations to 2022, which in turn are incompatible in important ways with themselves. And important implementations such as Jayway can't change very much, because they have thousands of artifacts depending on them, are incorporated into enterprise APIs, and have large existing user communities.

It does raise the suggestion that the IETF spec is not so much about standardizing existing practice, as it is about making something new. Perhaps it should be called something new, much as what started off as an IETF effort to standardize MessagePack became CBOR. The IETF spec is certainly as different from Goessner JSONPath and Jayway JSONPath as IETF CBOR is from MessagePack.

Daniel

from json-path-comparison.

I think Jayway's approach, if they want to implement the spec, would need to be to have a "spec-compliant" mode. Maybe even make that the default after a major version bump.

I'll update the above with reasons why some of these aren't included.

from json-path-comparison.

I think Jayway's approach, if they want to implement the spec, would need to be to have a "spec-compliant" mode. Maybe even make that the default after a major version bump.

I think Jayway is in maintenance mode, I don't think anybody there would undertake the effort. And besides, the draft's approach to expression evaluation is fundamentally different than Jayway's, or for that matter, any existing implementation up to 2022. I think most conforming implementations are going to be new implementations, I would have said all, except I understand json-everything is doing that! But for the most part, the old implementations that have users and artifacts dependent on them are going to stay the same.

from json-path-comparison.

I agree with that sentiment, and @hiltontj's recent efforts are proof.

Specifically, I think these wouldn't be too hard to support:

• JSON object and array literals in expressions
• leading and trailing whitespace tolerance
• in operator
• math operators
• relative paths (I fear we alienated the contributor who proposed this)

from json-path-comparison.

• relative paths (I fear we alienated the contributor who proposed this)

Indeed, but at least we learned something about what "rough consensus" really meant.

from json-path-comparison.

☝️ I've now added these things behind options in my lib. Really easy to implement.

from json-path-comparison.