-path should mostly be -query

[cabo]

The grammar (and some of the text) uses -path as a qualifier for embedded queries. This is confusing, as a query Is not a path. (normalized-path also is a query, but is used as a path and therefore is not addressed by this issue.)

[glyn]

I'm finding it hard to follow. I regard a path as a syntactic construct which can be fed into an implementation to perform a query. So paths can be embedded in other paths, all as part of running a query. I certainly agree that queries and paths are not the same things.

[cabo]

Interesting. For me a path is just that, a path through the tree. A result of the query, not the query itself. (Of course, some queries can be as simple as paths, which is why we can express normalized paths as queries.)

For the sake of the readers of this specification who have a mental model that is closer to this, we should avoid using the term "path" for JSONPath queries.

[gregsdennis]

I regard a path as a syntactic construct which can be fed into an implementation to perform a query. - @glyn

Yes, in the context of JSON Path, a "path" is the syntax that represents the query. But splitting that particular hair is like saying

SELECT *
FROM [Table]

is not a query; it's merely syntax. I think most people would colloqiually regard them as the same thing.

That said, I don't think that "path" in the context of JSON Path represents a path through the tree, but is more of a shorthand (or nickname) for "JSON Path." (Outside of this spec, yes, I would agree that it represents the path through the tree.)

I agree that we should probably either avoid it or rigidly define it.

[goessner]

I'm impressed by your work done up to here, thanks. I still need to catch up and go through those issues and PR's.

For my understanding a normalized-path surely is a path ... literally the JSONPath, as a target of a query. It can be used as a query though. Everything else used in the spec is more a query than a path. I agree, but don't mind, if we sometimes use 'path' as a synonym of a query.

[glyn]

I'd be happy to move from *-path to *-query if we define path as a path through the tree. But that leaves the term "JSONPath" high and dry. We could change the spec title to "JSONQuery", but I'm not sure we'd get away with it. Probably better to add some wording to explain why we want to use "JSONPath" in spite of it not making sense in spec terms.

[goessner]

To get the path of one or more value(s) inside of a JSON structure (tree) is sense and purpose of JSONPath. For this we are using queries. It makes perfect sense to keep the title "JSONPath".

[cabo]

We don't have to "define" the words that go into an ABNF rule name. We still need to minimize the amount of confusion.

For me (and undoubtedly many others), JSONPath is a brand that picks up on the wide use of XPath. This brand name does not change the meaning of "path", and removing some instances of "path" from ABNF names doesn't force us to change that brand name.

[cabo]

(I'll do a PR for this once #410 is decided.)