draft-ietf-jsonpath-base

draft-ietf-jsonpath-base copied to clipboard

NOTE I definitely think support for this proposal should not be part of the initial release but should be considered for follow-up releases. I had the idea and wanted to document it.

Scenario

Given the following JSON

[
  "foo",
  5,
  { "bar": null },
  "baz",
  null
]

there is no way to isolate only string values.

Proposal

To address this, we should introduce a type check.

I would like to propose the is operator for JSON Path expressions in the filter selector [?()]. Examples of usage would be:

@ is boolean
@ is string
@ is number
@.foo is object

To support this, we would need to reserve object, array, boolean, number, null, and string as reserved keywords in expressions, meaning that functions could not bear these names. I don't think that this would cause any problems.

It could also support value coercion on the RHS. For example @ is $.foo, could return true if $.foo is a string containing one of these type keywords.

A sub-par alternative

I had also considered a type(x) function to build on my proposal for functions.

The type(x) function would take a single parameter and return... well that's the problem. What would it return? It can't rightly return a string. It would have to return some implementation-internal concept of a "value type", and then we'd have to add support for equality.

type(@) == object and type(@) == "object" just don't feel right.

I think the is operator is the way to go for this feature.

A function syntax would have the advantage that it could use an extension point, while new syntax such as " is " always would lead to harder to manage syntax errors.

A function syntax would have the advantage that it could use an extension point, while new syntax such as " is " always would lead to harder to manage syntax errors.

I'm not sure why is would be any harder to parse than any other equivalence operator, e.g. == or !=.

And again, what would a function return? How would you test that a value is, for example, an array?

Captured as a request for enhancement.

Where was this captured? Isn't that the point of this issue? Why close it? It should be marked as an enhancement (done) and left open until added or we've decided we're not going to do it.

Actually, it should be labeled "revisit-after-base-done", which I just did. Thanks for catching this.