Re: ❓ JSON Path Dot Precedence

On Mon, Jul 8, 2024 at 8:27 AM David E. Wheeler <david(at)justatheory(dot)com>
wrote:

> Hi, following up on some old threads.
>
> > On Apr 10, 2024, at 16:44, David E. Wheeler <david(at)justatheory(dot)com>
> wrote:
> >
> > That makes sense, thanks. It’s just a little odd to me that the
> resulting path isn’t a query at all. To Erik’s point: what path can
> `'0x2.p10` even select?
>
> I’m wondering whether the jsonpath parser should be updated to reject
> cases like this. I think it will always return no results. AFAICT, there’s
> no way to navigate to an object identifier immediately after a number:
>
>
If we go down this path wouldn't the correct framing be: do not allow
accessors after scalars ? The same argument applies to false/"john" and
other scalar types since by definition none of them have subcomponents to
be accessed.

That said, the parser has a lax mode which somewhat implies it doesn't
expect the jsonpath type to perform much in the way of validation of the
semantic correctness of the encoded path expression.

I like the idea of a smarter expression-holding type and would even wish to
have had this on day one. Retrofitting is less appealing. We document a
similarity with regular expressions here where we, for better and worse,
have lived without a regexppath data type forever and leave it to the
executor to tell the user their pattern is invalid. Leaning on that
precedence here makes accepting the status quo more reasonable. Though
strict/lax modes and, I think, variables, motivates me to put my vote
toward the "do more validation" group.

Does the standard even have a separate type here or is that our
implementation detail invention?

David J.