@context has a very special behaviour in jsonpath

[vongohren]

Is it worth mentioning anywhere that it needs escaping for certain languanges? Or is that common knowledge?

Even, libraries have different escaping mechanisms, atleast in Node:

jsonPath: "$..['@context'][1]" jsonPathPluss: "$..['`@context'][1]"

Notice the subtle differenc of `.

What might the best approach be. Special handling at application and library level maybe? Because this escape mechanism might be different from Java, Go, and so on?

Maybe this spec needs to define one way of using context, and then everyone will handle it differently at their implementation level?

It is kinda related to #274, meaning that implementations can turn out different results

[JaceHensley]

Oh that's really interesting, it seems like the problem is that the original (? only one I could find) spec for JSON Path doesn't mention escaping at all

Related issues: https://github.com/dchester/jsonpath/issues/138, https://github.com/JSONPath-Plus/JSONPath/issues/154

[vongohren]

@JaceHensley yeah and as mentioned in the attached issue, there are certain comparission(standard) work going on. Link to github page working on this: https://github.com/cburgmer/json-path-comparison

[kimdhamilton]

I hate this bug

[nklomp]

LOL, this is a known issue in our PE implementation as well ;)

We hate it too @kimdhamilton , and have not gotten around to fixing it yet.

The first reaction is to escape it on the PE implementation, but then there are also valid @ possibilities that are not related to json-ld. We probably will settle for having a list of known/mostly used JSON-LD keywords in our implementation.

[vongohren]

Glad to hear we share the pain, and I believe we will converge more on this going forward when more PE implementations surface. So believe this should stay open for a bit

[csuwildcat]

I played around with a bunch of JSONPath libs/evaluation sites and can't figure out if they all have done some augmentation or if this is already part of the grammar, but this appears to be supported:

Example object:

{
 "@context": ["https://example.com"]
}

Expression:

$.['@context']

[JaceHensley]

So the JSONPath string would just be "$.['@context']"

[vongohren]

@csuwildcat did you try out this test suite? https://github.com/cburgmer/json-path-comparison

[csuwildcat]

I filed an issue on the JSONPath IETF repo and they promptly informed me that querying for properties with special characters using bracket notation already is the standard form that allows for selection of properties that have characters like @ in them: https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/189

Any issues folks have brought up here must be with a lib that doesn't conform to the spec, but in my testing, most libs are handling this properly, as the spec directs them to.

[csuwildcat]

ACTION: not just Dan list in this issue, for the purpose of inclusion in the spec, the JSONPath libs that conform to the spec and allow you to select properties with @ signs in them.

[gregsdennis]

a lib that doesn't conform to the spec

Nothing conforms to the spec yet because the spec isn't done. The entire reason we're writing a spec is that implementations deviate in their feature set.