search

ietf-wg-jsonpath / draft-ietf-jsonpath-base

Development of a JSONPath internet draft
https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-base/
Other
59 stars 20 forks source link

Normalized nodelists #293

Closed glyn closed 1 year ago

glyn commented 1 year ago

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/289 begs the question of whether nodelists should have a normalized form. This would improve the interoperation, predictability, etc. of JSONPath implementations that output nodelists.

Without this, JSONPath implementations which output nodelists would likely choose multiple different ways of representing nodelists.

The proposal is for a Normalized Nodelist to consist of a possibly empty, whitespace separated list of Normalized Paths as in the following ABNF:

normalized-nodelist = [normalized-path *(S normalized-path)]

Note: this proposal does not provide a normalized form for output from JSONPath implementations that output both nodelists and values.

goessner commented 1 year ago

good approach ... I would prefer a comma separated list, being able to be consumed as a JSON array without further modification ...

goessner commented 1 year ago

ohh ... and the norm.pathes as JSON strings, i.e.

normalized-nodelist = ["normalized-path" *(,S "normalized-path")]
cabo commented 1 year ago 
normalized-nodelist = [normalized-path *(S normalized-path)]

I don't think we want to do this. This is not a JSONPath query, but a structure built from that. I'd like to leave structure building to JSON entirely. We are not defining the syntax of JSON, and we should avoid falling into the restatement antipattern trap.

So yes, a nodelist might look like ["$", "$.foo"], but not because we say so, but because that is JSON syntax. We would simply say nodelists are canonically represented as JSON arrays of strings, where the strings are normatlizedpaths.

goessner commented 1 year ago

yes ... that's even better and pragmatical.