Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2

From: Daniel P <[email-masked]>
Date: Wed, 25 Nov 2020 17:45:02 -0500

> From: Glyn Normington <[email-masked]>
> Subject: Re: [Jsonpath] Remarks on the array slice operator described in https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2
> I took a crack at those editorial changes. Please see:
>
> https://github.com/jsonpath-standard/internet-draft/pull/41
>

This draft is evolving nicely, in my opinion, I'm certain that implementators
will be appreciative of your efforts. I still dislike the use of
"union element" in the definition of terms like "slice". Comparable
specifications define "slice" by itself, without reference to where it
is used. For that matter, I dislike the term "union", as conceptually
these cannot sensibly be considered unions in an algebraic sence. I
prefer the analogous JMESPath nomenclature, "MultiSelect list".

More comments:

(1) "A JSON Path is a", "A JSON Path MUST be" p. 1

Goessner never uses "JSON Path", Goessner consistently uses JSONPath

(2) "A JSON Path is a string which selects zero or more nodes of any
JSON document" p.1

"A JSON document is logically a tree of nodes with the document as the root
node of the tree." p. 1

A JSONPath is an expression that when applied against JSON, returns JSON.
Why introduce "JSON document" and "node"? RFC8259 makes no mention of
"JSON document" or "node". Neither does ECMA-404 2nd edition. Goessner
refers to "XML documents" and XPath nodes, but not to JSON documents
or nodes.

(3) "When step is 0, no elements are selected. This is the one case
which differs from the behaviour of Python, which raises an error in
this case." p. 10

Is there a rationale for that choice? As you note, in Python it is an
error. In JMESPath it is also an error, see
https://jmespath.org/specification.html#slices.

Unless I've missed it, Christoph Burgmer doesn't have a test case for
a slice where step is zero. Perhaps we can prevail upon him to add
one.

(4) "union-child" p.7

"union-child" is awkward, why not call it "quoted-string"?

Daniel

---

From: Marko Mikulicic <[email-masked]>
Date: Thu, 26 Nov 2020 10:47:19 +0100

> Comparable specifications define "slice" by itself,

The slicing specification is quite complex. I was wondering if we could
treat it as a "sub-specification", where we can talk about slices in
abstract terms that don't need to reference other concepts from jsonpath.

In particular, I was thinking of modeling a slice expression as a function
from 4-tuples to integer sequences, e.g. {start: 1, end: 10, step: 2, len:
9} -> [1,3,5,7],
and then treating this integer sequence as if the user explicitly passed it
as indices in an array access expression.

(A minor side effect of this choice would be that we can change what we
call those indices in the array access expression without affecting the
slicing sub-specification)

On Wed, 25 Nov 2020 at 23:45, Daniel P <[email-masked]> wrote:

> > Subject: Re: [Jsonpath] Remarks on the array slice operator described in
> https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2
> --
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 09:49:36 +0000

Thanks for these comments Daniel. Responses inline.

It would be better to make comments in the pull request for ease of threading and so other reviewers see them in context. Would you be happy to do that?

Regards,
Glyn

> Goessner never uses "JSON Path", Goessner consistently uses JSONPath

Yes, I know. I don’t mind switching if there’s a general preference for “JSONPath”.
The WG is entitled “JSON Path”, so it’s not obvious what the consensus is. Deferring for the moment.

> refers to "XML documents" and XPath nodes, but not to JSON documents

Phrases like “applied against JSON” feel imprecise. A JSONPath isn’t applied to
the notation per se, but to something written in the notation.

Perhaps we should simply adopt the language of RFC 8259 and talk about “a JSON text”
instead of “a JSON document”.

> https://jmespath.org/specification.html#slices.

The rationale is the supposed consensus of implementations.

> a slice where step is zero. Perhaps we can prevail upon him to add

I will add that test.

> "union-child" is awkward, why not call it "quoted-string"?

I wanted to give a better hint of the intended use. For now, I’ve renamed this to “child” (as opposed to “dot child”).

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 10:22:45 +0000

On 26 Nov 2020, at 09:49, Glyn Normington <[email-masked]> wrote:
>> https://jmespath.org/specification.html#slices <https://jmespath.org/specification.html#slices>.
> 

It turns out there is such a test already, but no consensus:

https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html <https://cburgmer.github.io/json-path-comparison/results/array_slice_with_step_0.html>

Maybe raising an error to be consistent with Python would be a good move. What do others think?

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 10:49:08 +0000

On 26 Nov 2020, at 09:49, Glyn Normington <[email-masked]> wrote:
> 
> On 25 Nov 2020, at 22:45, Daniel P <[email-masked] <mailto:[email-masked]>> wrote:
>> 

On reflection, switched to JSONPath. Let’s see if there’s any push-back.

> instead of “a JSON document”.

Switched to “JSON text”.

---

From: Daniel P <[email-masked]>
Date: Thu, 26 Nov 2020 10:38:40 -0500

> instead of “a JSON document”.
ECMA-404 2nd edition defines a JSON text as "a sequence of tokens formed from
Unicode code points that conforms to the JSON value grammar", and suggests an
abstract understanding of "JSON value", the JSON value grammar is defined
without mentioning text. RFC 8259 is less clear, it describes a JSON text as
"a serialized value", but then in the grammar defines

JSON-text = ws value ws

Given that the input and output to a JSONPath search function is
rarely literally text,
I'd personally  be inclined to "JSON value" with reference to ECMA-404
2nd edition. But that's just me, I'm certain that others here can
comment on this
more authoritatively.

Daniel

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Nov 2020 16:47:47 +0100

> "a serialized value”,

Exactly that.  “JSON text” is the encoded data item, which is not what JSONpath operates on.  The actual data item encoded by the JSON text is not discussed in ECMA-404 (which would make this a useless document if there weren’t others around that point the way).  “JSON value” is an acceptable way to talk about the JSON data item, so if congruence with RFC 8259 is desirable, this should be the way to go.
(The end of the examples section uses “only values” as “only atomic values”, but I think we can ignore this lapse — RFC 8259 is the result of a rather tortuous process where editorial consistency wasn’t always the main objective.)

> but then in the grammar defines
> 
> JSON-text = ws value ws

Yes, because in the grammar, each of the productions (value, object, array, string…) define the representation of the data item that is named in its name; so the production “value” defines how to represent a “JSON value”.
This is fully consistent.

> Given that the input and output to a JSONPath search function is

Exactly.

> 2nd edition. But that's just me, I'm certain that others here can

If there were no precedence, I’d use “JSON data item”, but “JSON value” works.
(Unfortunately, following RFC 8259 also imports “object”, which I think we should never use without the “JSON” prefix.)

Grüße, Carsten

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 15:54:25 +0000

> (Unfortunately, following RFC 8259 also imports “object”, which I think we should never use without the “JSON” prefix.)

Ok, I've switched from “JSON text” to “JSON value” in the PR.