Subject: [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: Sat, 14 Nov 2020 14:30:51 -0500

> From: Glyn Normington <[email-masked]>
>> On 12 Nov 2020, at 17:37, Daniel P <[email-masked]> wrote:

>> Note that a slice expression in Goessner is defined with reference to
>> the (long since abandoned) ECMASCRIPT 4. The original link is lost,
>> but there is some discussion here,
>>https://web.archive.org/web/20070125020659/developer.mozilla.org/es4/proposals/slice_syntax.html.
>
> We plugged that gap in the Gössner article thus:
>
> https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2
>
> which may be a safer starting point for the WG.
>
Thanks! The ABNF for an array slice in that reference

integer = [%x2D] (%x30 / (%x31-39 *%x30-39))

array-slice = [ integer ] ws %x3A ws [ integer ]
                   [ ws %x3A ws [ integer ] ]
                            ; start:end or start:end:step

is consistent with JMESPath, Python, and my understanding of
ECMASCRIPT 4. Perhaps the comment could be expanded to highlight that
all integer parts are optional.

I think this sentence is awkward:

"An array slice is a union element consisting of two or three integers
(in base 10 and which may be omitted) separated by colons."

More specifically, the use of the term "union element" seems to me to
be unnatural and unnecessary. Nothing would be lost by substituting
"An array slice consists of ..."

Moreover, Goessner uses the term "union" once in
https://goessner.net/articles/JsonPath/, and appears to be referring
to expressions of the form

union = "[" ( expression *( "," expression ) ) "]"

where minimally one comma is required (Goessner's shorthand notation is [,]).

Daniel

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 14 Nov 2020 21:08:09 +0100

>                            ; start:end or start:end:step

Looks good.  From an editorial point of view, I’d use a separate definition DIGIT and DIGIT1 for %x30-39 and %x31-39 for readability.  I’d also use "-" and "0" for the non-range terminals %x2D and %x30.  (It may occasionally be necessary to use hex outside ranges, i.e., for case-sensitive letters, unless we want to use the ABNF extensions for case-sensitive letters in RFC 7405 — e.g., for the escapes.  Please see the end of https://tools.ietf.org/html/rfc4997#page-44 for how this can be kept readable.)

> all integer parts are optional.

That is clearly said in the ABNF, but it certainly doesn’t hurt to spell this out in English as well.
(Also, the third colon with the optional integer following is optional.)

The most obvious misunderstanding trap that is set up in the above draft is HEXDIG; this needs a English language comment that the letters A-F are indeed case-insensitive (i.e., also a-f).

> (in base 10 and which may be omitted) separated by colons."

I think what this is trying to say is that [0:3] is exactly equivalent to [0, 1, 2], which is a union operator, so the result of [0:3] should also be what can be called a “union element”.  Detailed terminology to be fixed...

> where minimally one comma is required (Goessner's shorthand notation is [,]).

The ABNF in draft-goessner-dispatch-jsonpath-00.txt merges this case with the single value-expression case, so [3], [3, 4], and [3, 4, 5] are handled by the same production, making the result of [3] a (trivial) union as well.

Grüße, Carsten

---

From: Glyn Normington <[email-masked]>
Date: Tue, 17 Nov 2020 15:20:51 +0000

The improvements below are welcome. I’ve made one clarification below.

On 14 Nov 2020, at 20:08, Carsten Bormann <[email-masked]> wrote:
> 
> On 2020-11-14, at 20:30, Daniel P <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Looks good.  From an editorial point of view, I’d use a separate definition DIGIT and DIGIT1 for %x30-39 and %x31-39 for readability.  I’d also use "-" and "0" for the non-range terminals %x2D and %x30.  (It may occasionally be necessary to use hex outside ranges, i.e., for case-sensitive letters, unless we want to use the ABNF extensions for case-sensitive letters in RFC 7405 — e.g., for the escapes.  Please see the end of https://tools.ietf.org/html/rfc4997#page-44 <https://tools.ietf.org/html/rfc4997#page-44> for how this can be kept readable.)
> 

I added “is a union element" to remind the reader that an array slice is just one kind of union element. That may not be necessary.

I wasn’t thinking of any equivalence between an array slice and a union of array indices, although that’s an interesting observation, especially as we address the more general questions of duplication and ordering.

>> https://goessner.net/articles/JsonPath/ <https://goessner.net/articles/JsonPath/>, and appears to be referring
> -- 
> Jsonpath mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jsonpath <https://www.ietf.org/mailman/listinfo/jsonpath>

---

From: Glyn Normington <[email-masked]>
Date: Wed, 25 Nov 2020 16:54:19 +0000

I took a crack at those editorial changes. Please see:

https://github.com/jsonpath-standard/internet-draft/pull/41 <https://github.com/jsonpath-standard/internet-draft/pull/41>

> On 17 Nov 2020, at 15:20, Glyn Normington <[email-masked]> wrote:
> 
> On 14 Nov 2020, at 20:08, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> From: Glyn Normington <[email-masked] <mailto:[email-masked]>>
>>>>> On 12 Nov 2020, at 17:37, Daniel P <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> https://web.archive.org/web/20070125020659/developer.mozilla.org/es4/proposals/slice_syntax.html <https://web.archive.org/web/20070125020659/developer.mozilla.org/es4/proposals/slice_syntax.html>.
>>>> 
>>>> https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2 <https://jsonpath-standard.github.io/internet-draft/#name-array-selector-2>
>>>>