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

[Glyn Normington <[e-mail]>]

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

On 14 Nov 2020, at 20:08, Carsten Bormann <[e-mail]> wrote:
> 
> On 2020-11-14, at 20:30, Daniel P <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> From: Glyn Normington <[e-mail]>
>>>> On 12 Nov 2020, at 17:37, Daniel P <[e-mail]> 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
> 
> 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.)
> 
>> 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.
> 
> 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).
> 
>> 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."
> 
> 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...

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.

> 
>> 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/ <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 [,]).
> 
> 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
> 
> -- 
> Jsonpath mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jsonpath <https://www.ietf.org/mailman/listinfo/jsonpath>