draft-ietf-jsonpath-base

draft-ietf-jsonpath-base copied to clipboard

Backgroud: I need to do some translation of a dedicated string field from Chinese to other languages, but some fields live inside a internal json object string( a json object, but a jsonString type`.

{
  "data": {
    "header_1": {
      "a": "1",
      "b": "2",
      "body": "{\"c\":\"3\"}"
    },
    "header_2": {
      "a": "1",
      "b": "2",
      "body": "{\"c\":\"3\"}"
    }
  }
}

With the current java jsonpath:

//to json
{"data":{"header_1":{"a":"1","b":"2","body":{"c":"3"}},"header_2":{"a":"1","b":"2","body":{"c":"3"}}}}
// update `c`
{"data":{"header_1":{"a":"1","b":"2","body":{"c":"6666"}},"header_2":{"a":"1","b":"2","body":{"c":"6666"}}}}
//conver back
{"data":{"header_1":{"a":"1","b":"2","body":"{\"c\":\"6666\"}"},"header_2":{"a":"1","b":"2","body":"{\"c\":\"6666\"}"}}}

I more like to do this in a one run. eg:

$.data[/header_\d+/].body[@toJson()].c[@translate()]

Just like the GraphQL's directives https://www.apollographql.com/docs/apollo-server/schema/directives/#custom-directives

As I mentioned in #516, I don't think JSON Path is the right tool for you.

Also, have a look at the conversation in #514 as to why mutation of data, even internally, isn't likely to happen.

I just implemented it internally, but this would be a nice addition, graphql is a query language so does jsonnet, I think it's pretty valid to extends it with directives, which operates on the selected nodes, and the default behavior is identity function.

I took this from graphql , jaywalking Jason path have a pathfunction which let you do this too.

And it has a update and set method.

graphql is a query language so does jsonnet

I'm quite familiar with both of these.

These languages can query, but they can also do a lot more, including mutation. JSON Path is only a query language. It does not mutate. It's read-only.

graphql is a query language so does jsonnet

I'm quite familiar with both of these.

These languages can query, but they can also do a lot more, including mutation. JSON Path is only a query language. It does not mutate. It's read-only.

It's not read only, I implement one and still use it at work, directive can modify the node , as @uppercase

You misunderstand.

JSON Path, per the original idea and the specification, is definitely read-only. Any behavior that you might add to your implementation is extension behavior and not compliant with the spec. As such it should be disabled by default.

You misunderstand.

JSON Path, per the original idea and the specification, is definitely read-only. Any behavior that you might add to your implementation is extension behavior and not compliant with the spec. As such it should be disabled by default.

Yes and no, with the directive, the implementation can achieve me and still fulfill the spec.

Part of implementing the specification is failing when it's supposed to. If you support extra syntax, it won't fail.

If jsonpath support directive/function and | like jq which will be very powerful.

Ideally something like jq, which uses the "path" term but does not claim to use JSON Path, could update to use JSON Path and build upon it.

This concept is similar to #514 in that it adds a new operating mechanic, and you're welcome to read the reception that idea had.