Subject: [Jsonpath] Controversial issues

From: Daniel P <[email-masked]>
Date: Thu, 5 Nov 2020 16:49:18 -0500

From: Glyn Normington <[email-masked]>
>
> The following issues are suitably controversial:

> * Removal of duplicates from results: https://github.com/jsonpath-standard/internet-
> draft/issues/23

I don't think any implementation would remove duplicates from a path
such as "$.store.book". I believe this is only somewhat controversial
in the context of unions [,]. The name "union" suggests that distinct
values be returned, compare with SQL unions. But Stefan Goessner's
implementation doesn't do that, it concatenates all results that meet
each criteria. There are a few JSONPath implementations that produce
real unions with no duplicates instead of concatenated results, but I
don't think that's the consensus.

Daniel

---

From: Daniel P <[email-masked]>
Date: Thu, 5 Nov 2020 18:10:05 -0500

On 5 Nov 2020, at 11:14, Carsten Bormann <[email-masked]> wrote:

> The underlying problem here is that of a missing model.
> XPath has nodesets, and we probably need something like that.

Unlike XPath, where an expression can return items that are
not XML documents, a JSONPath expression can only return
JSON values, and a collection of JSON values can be
returned in a JSON array value. Consequently, introducing
the idea of node-sets into JSONPath would seem to
serve no purpose.

Daniel

---

From: Tim Bray <[email-masked]>
Date: Thu, 5 Nov 2020 15:19:07 -0800

In the heavily JSONPath-dependent app I most recently worked on, when
applying a JSONPath returned multiple values, we exposed that as a JSON
array.  Not religious about this issue, but the return-an-array seemed to
surprise nobody and make people happy.

On Thu, Nov 5, 2020 at 3:10 PM Daniel P <[email-masked]> wrote:

> --
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 00:20:42 +0100

On 2020-11-06, at 00:10, Daniel P <[email-masked]> wrote:
> JSON values,

That may be trivially true, but these values can be values from the input tree, or they can be positions in the tree.  A set of positions is very much like a node set.
I was less interested in the output formats than in the information that is kept as part of the processing model, and that might indeed also include sets of positions.

Grüße, Carsten

> and a collection of JSON values can be

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 00:24:01 +0100

On 2020-11-06, at 00:19, Tim Bray <[email-masked]> wrote:
> 
> In the heavily JSONPath-dependent app I most recently worked on, when applying a JSONPath returned multiple values, we exposed that as a JSON array.  Not religious about this issue, but the return-an-array seemed to surprise nobody and make people happy.

I wasn’t even aware that there is a question here.

https://www.ietf.org/archive/id/draft-goessner-dispatch-jsonpath-00.html#name-return-value

(Clearly, I would get rid of the “false” special case — an empty array is fine.)

Grüße, Carsten

---

From: Michael Kay <[email-masked]>
Date: Thu, 5 Nov 2020 23:35:42 +0000

> In the heavily JSONPath-dependent app I most recently worked on, when applying a JSONPath returned multiple values, we exposed that as a JSON array.  Not religious about this issue, but the return-…

How does the receiving application determine whether a result of [1,2,3] represents a single value retrieved from the JSON source, or a collection of three separate values retrieved from the JSON source?

Michael Kay
Saxonica

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Nov 2020 00:37:14 +0100

> How does the receiving application determine whether a result of [1,2,3] represents a single value retrieved from the JSON source, or a collection of three separate values retrieved from the JSON s…

You always get an array, so if the single value is [1, 2, 3], you get [[1, 2, 3]].

Grüße, Carsten

---

From: Michael Kay <[email-masked]>
Date: Thu, 5 Nov 2020 23:40:40 +0000

That makes sense. I read Tim's "when [returning] multiple values" as "when and only when".

Michael Kay
Saxonica

> On 5 Nov 2020, at 23:37, Carsten Bormann <[email-masked]> wrote:
>

---

From: Daniel P <[email-masked]>
Date: Thu, 5 Nov 2020 18:46:05 -0500

Yes, that's certainly the intention expressed by Stefan Goessner in
https://goessner.net/articles/JsonPath/:

"Please note that the return value of jsonPath is an array, which is
also a valid JSON structure. So you might want to apply jsonPath to
the resulting structure again or use one of your favorite array
methods as sort with it."

Daniel

---

From: Daniel P <[email-masked]>
Date: Thu, 5 Nov 2020 19:07:25 -0500

On Thu, Nov 5, 2020 at 6:20 PM Carsten Bormann <[email-masked]> wrote:
> That may be trivially true, but these values can be values from the input tree, or they can be positions in the tree.

A query can return either JSON values or normalized JSON paths
(strings), but not both. I don't believe there are any existing
JSONPath implementations that support examining the paths while
retrieving values. Consequently the JSON data model can support both.

In implementations that support paths (the majority don't), the query
function takes a parameter that indicates values or paths. In both
cases the query returns a JSON array of JSON values, in the latter
case, a JSON array of normalized paths.

> A set of positions is very much like a node set.

In existing implementations, it is a JSON array of JSON string values.

Daniel

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Nov 2020 17:05:37 +0100

> In existing implementations, it is a JSON array of JSON string values.

As I pointed out in the meeting today, it *is represented* as a JSON array.
It *is* pretty much a node set.

(I was pleading for separating implementation/API issues from the mental model that we use for describing JSONpath.  Multiple APIs can support different use cases for a single model.)

Grüße, Carsten

---

From: Daniel P <[email-masked]>
Date: Mon, 16 Nov 2020 22:24:09 -0500

> It *is* pretty much a node set.

Okay, I'm clearly not understanding something.

Assuming a "node set" is a collection of nodes, what do you mean by
"node"? Is it analogous to the use of "Element Node" in the XQuery and
XPath Data Model as described in
https://www.w3.org/TR/xpath-datamodel-31/#ElementNode?

If so, what type of node do you think you need in addition to values
that satisfy the JSON value grammar, as described in
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf.

When you used the term "positions" above, I think you're referring to
Goessner's function

jsonPath(obj, expr [, args])

that can either return matching values (if args.resultType is
"VALUE"), or a list of the normalized path expressions that would
produce those values if evaluated against the same JSON object|array
(if args.resultType is "PATH").

Is that correct? That by "positions" you mean Goessner's "normalized
path expressions"?

But why would a function that returns "normalized path expressions"
have implications for the JSONPath data model?

Thanks,
Daniel

---

From: Michael Kay <[email-masked]>
Date: Tue, 17 Nov 2020 09:12:35 +0000

> https://www.w3.org/TR/xpath-datamodel-31/#ElementNode?

Indeed, I've been struggling with the same question (not just in the context of JsonPath, but also in devising primitives to assist with manipulation of JSON in XPath and XSLT).

I think the key difficulty is whether each (key, value) pair in an object is "a thing" that can be identified and manipulated and potentially returned. (If we're talking analogies, then it's analogous to an attribute node in the XDM model).

Michael Kay
Saxonica