JSONPath response data model

[farshidtz]

The current spec has the following assertion for both JSONPath and XPath responses:

... in the body a set of complete TDs or a set of TD fragments.

We need to check if this is valid.

What happens when a single attribute is selected? What about functions (e.g. count)?

Raised in #153

For XPath, please refer to #247

[AndreaCimminoArriaga]

Would not be a string (single attribute) just a TD fragment? is still a part of a major TD, why should it not be a TD fragment?
Are you proposing to define a kind of json body wrapping the search results?

[farshidtz]

It will not always be a set of TD fragments. The result could be a single fragment:

5

for counting or

"urn:example:some-td"

for querying just an id.

Note that the above are valid JSONs; see https://datatracker.ietf.org/doc/html/rfc8259#section-13.

[farshidtz]

For JSONPath, this seems to be implementation-specific right now.

Picking a single object/element is not always returned as an array: See Nebhale: https://jsonpath.herokuapp.com/
Or as mentioned above, some aggregator functions will not give arrays.

But the IETF draft suggests returning list always so our text would be correct:
https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base-00#section-3.5

[mmccool]

Note there is a new version now: https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base-01

[mmccool]

Problem is, JSONPath is currently a moving target and the IETF RFC is unlikely to be finalized prior to our (original) target date for a Discovery PR. So we have a couple of choices:

1. Wait on our REC until JSONPath IETF RFC is complete
2. Make XPath the "primary" query mechanism, make JSONPath optional/experimental
   • In 1.1 can adopt the JSONPath standard
   • XPath could be optional or mandatory
   • It would be good to have at least on mandatory query type
   • Right now only have one XPath implementation
3. Do nothing, leave JSONPath as primary and mandatory
   • but... can't depend on draft IETF spec
   • ... so not really an option

[mmccool]

4. Make all query types optional.
5. Write JSONPath spec inside Discovery spec. But: large, may drift from "official" spec to come.
6. Like 5, but allow only a small subset of simple queries for targeted use cases, picking things that are unlikely to change. Ex: keyword search, search based on @type. Look at what we did for Node-RED, for instance... (@relu91 has volunteered to look into this).

[mmccool]

During the F2F Carsten Bormann noted that the JSONPath group was seeking feedback but this is needed immediately (the next IETF meeting is next week, and there are various deadlines for locking down the specs imminent). So we should immediately review the JSONPath document and provide feedback on our primary use cases (e.g. limited keyword search, perhaps string matching). @relu91 had volunteered to do this during the F2F so I will reach out to him via email.

[k-toumura]

(I apologize for not being able to respond in the last meeting due to equipment trouble.)

@farshidtz has summarized the issue I had when I tried to query using JSONPath in my previous integration with Node-RED: w3c/wot-testing#29 .
I haven't read the latest JSONPath spec yet. Does anyone know whether this inability to query is an implementation limitation or a limitation of the JSONPath specification?

[relu91]

@farshidtz has summarized the issue I had when I tried to query using JSONPath in my previous integration with Node-RED: w3c/wot-testing#29 .
I haven't read the latest JSONPath spec yet. Does anyone know whether this inability to query is an implementation limitation or a limitation of the JSONPath specification?

I'm reviewing the spec as @mmccool asked and I think this is a JSONPath limitation. So as @farshidtz noted JSONPath has a special operator to access descendants of a particular node, the so-called Descendant Selector (which is basically ..). Looking into ABNF rules of the Filter Selector it is not possible to use that Descendant Selector together with @ :

rel-path     = "@" *(dot-selector / index-selector) ; <--- here we are missing "descendant-selector" rule

So my conclusion would be that is a JSONPath limitation. What is not clear to me (and maybe we might need to ask for help) is that inside the filter selector as a boolean expression we can use as a path a valid json-path query:

basic-expr   = exist-expr / paren-expr / (neg-op paren-expr) / relation-expr ; expression rule
exist-expr   = [neg-op] path                          
path         = rel-path / json-path              ; notice how we can use a valid json path as argument. 
rel-path     = "@" *(dot-selector / index-selector)

The document is not really clear about how a json-path should be evaluated inside a Filter Selector.

[relu91]

Digging further on the problem it seems that major JSON-path implementations do not really support filtering with recursive descent: https://cburgmer.github.io/json-path-comparison/results/filter_expression_after_dot_notation_with_wildcard_after_recursive_descent.html ;
https://cburgmer.github.io/json-path-comparison/#filter_expression_with_value_from_recursive_descent (scroll a little bit up to see clearer)

[relu91]

During the F2F Carsten Bormann noted that the JSONPath group was seeking feedback but this is needed immediately (the next IETF meeting is next week, and there are various deadlines for locking down the specs imminent). So we should immediately review the JSONPath document and provide feedback on our primary use cases (e.g. limited keyword search, perhaps string matching). @relu91 had volunteered to do this during the F2F so I will reach out to him via email.

I moved the discussion to #232, cause I'm feeling that we are a little bit out of topic for this issue. It seems that the original question is already addressed by @farshidtz comment:

For JSONPath, this seems to be implementation-specific right now.

Picking a single object/element is not always returned as an array: See Nebhale: https://jsonpath.herokuapp.com/
Or as mentioned above, some aggregator functions will not give arrays.

But the IETF draft suggests returning list always so our text would be correct:
https://datatracker.ietf.org/doc/html/draft-ietf-jsonpath-base-00#section-3.5

What I can say is that even in the new document I got the impression that implementers are required to return always a list too.

[farshidtz]

I've split the XPath concern to another issue: #247

To summarize: According to the draft IETF JSONPath spec, the responses are always lists and there is no support for aggregation functions. This is inline with the statements in the discovery spec.

Other topics discussed here are not relevant and can be continued elsewhere (see references above).