cburgmer/json-path-comparison

Optionally return path to item instead of item itself

gregsdennis opened this issue · 7 comments

Goessner's original post declares that the return type (array form) could either be the found items or the JSON Paths to those items. Is there any intent to check for this kind of output in the future? Have you seen any libraries support this?

return value:
(array|false):
Array holding either values or normalized path expressions matching the input path expression, which can be used for lazy evaluation. false in case of no match.

My remorhaz/php-json-path supports returning paths (with one of these methods of processor). But I don't think that checking this behaviour is of big value: the main problem is that different implementations select different values, not paths.

We could include it in the scope.
I would probably only invest if enough libraries support this operation and there's a tendency to agree on a similar response type.

I know of the Clojure implementation also supporting this, as I implemented it 3 years ago :)

But what we should check in this case? For example, implementation X returns $.a.b, and implementation Y returns $["a"]["b"] as a path string. The expressions are different, but they do the same work and return the same value.

The question is - is there any reason for the paths not to be different?

If we see that response formats are different, we might be able to write a trivial transformation.

As for why answers should be different, I would expect less deviation once the actual JSONPath responses are aligned. However I wouldn't rule out misalignment there either, I'm always surprised what I find once I dare to check.

Maybe it's sufficient to just have a check to see if it's supported for a given library.

If the unit JSON has unique values, then testing on the values returned would be good enough to know that the query did what we expect.

From there, it's a reasonable assumption that the paths to the values would be correct.

Goessner, when discussing dot notation and bracket notation, says that "...output paths will always be converted to the more general bracket–notation", which suggests the correct return value would be $['a']['b'], not $.a.b.

While I understand the tendency to use JSON Path for the locations (seeing as that's what we're building, which is likely why Goessner suggested it), I don't think that it's appropriate for this use case. JSON Pointer is more appropriate here since it's designed to isolate and identify a single value from a document. JSON Path is a query syntax and returns an array of values.

JSON Pointer is an extremely simple syntax that's already in spec and has wide library support.