Subject: [Jsonpath] Partial determinism of the descendant selector (..)

From: Glyn Normington <[email-masked]>
Date: Mon, 16 Aug 2021 15:07:24 +0100

This topic is covered in issue 103
<https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/103>,
which seems to have stalled, so let me put the main options to the mailing
list to try to discern any consensus.

Regardless of the detailed language, please could you indicate which of
these options you favour:

A. Don't tie down the non-determinism of .. at all

B. Require .. to visit arrays in array order and visit nodes before their
descendants

C. Some other option involving B with the option of A or A with the option
of B, using some kind of language TBD.

D. Something else, in which case please say what.

Regards,

Glyn

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Aug 2021 16:50:07 +0200

On 2021-08-16, at 16:07, Glyn Normington <[email-masked]> wrote:
> 
> This topic is covered in issue 103, which seems to have stalled, so let me put the main options to the mailing list to try to discern any consensus.
> Regardless of the detailed language, please could you indicate which of these options you favour:
> 
> B. Require .. to visit arrays in array order and visit nodes before their descendants

Yes.
(There is no order in maps, so this is as deterministic as it can get.)
BTW, the term “pre-order” [1] is in wide use as a handy term for "visit nodes before their descendants” (we would still define it that way).

> C. Some other option involving B with the option of A or A with the option of B, using some kind of language TBD.

Yes, as well :-).
We haven’t really discussed levels of compliance, and a version of “doesn’t return .. in order” could be a form of conditional compliance.
*If* we think we need this to drag some implementations along.
(That is, I’d like to hear arguments of the form “We’d lose foomatic’s JSONPath implementation because they make a point of returning arrays in reverse order on Fridays” before we load ourselves with conditional compliance.)

Grüße, Carsten

[1]: https://en.wikipedia.org/wiki/Tree_traversal#Pre-order,_NLR
(This article talks about binary trees only, probably because they want to discuss in-order as well, which only makes sense for binary trees.)

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

---

From: Glyn Normington <[email-masked]>
Date: Tue, 17 Aug 2021 11:43:08 +0100

On Mon, 16 Aug 2021 at 15:50, Carsten Bormann <[email-masked]> wrote:

> > This topic is covered in issue 103, which seems to have stalled, so let
> me put the main options to the mailing list to try to discern any consensus.
> BTW, the term “pre-order” [1] is in wide use as a handy term for "visit
> nodes before their descendants” (we would still define it that way).
>

At the risk of another digression, pre-order is more prescriptive than
"visit nodes before their descendants". Take this example from [1]:

Pre-order traversal would be "F, B, A, D, C, E, G, I, H", but "visit nodes
before their descendants” allows more possibilities, such as "F, B, G, A,
D, C, I, E, H".

By being less prescriptive, I was trying to allow for parallel
implementations.

>
> > C. Some other option involving B with the option of A or A with the
> option of B, using some kind of language TBD.
>
> Yes, as well :-).
> We haven’t really discussed levels of compliance, and a version of
> “doesn’t return .. in order” could be a form of conditional compliance.
> (That is, I’d like to hear arguments of the form “We’d lose foomatic’s
> JSONPath implementation because they make a point of returning arrays in
> reverse order on Fridays” before we load ourselves with conditional
> compliance.)
>
> Grüße, Carsten
>
> (This article talks about binary trees only, probably because they want to
> discuss in-order as well, which only makes sense for binary trees.)
>