On Jul 8, 2024, at 12:05, David G. Johnston <david.g.johnston@gmail.com> wrote:
> If we go down this path wouldn't the correct framing be: do not allow accessors after scalars ? The same argument
appliesto false/"john" and other scalar types since by definition none of them have subcomponents to be accessed.
Yes, excellent point.
> That said, the parser has a lax mode which somewhat implies it doesn't expect the jsonpath type to perform much in
theway of validation of the semantic correctness of the encoded path expression.
My understanding is that lax mode means it ignores where the JSON doesn’t abide by expectations of the path expression,
notthat the path parsing is lax.
> I like the idea of a smarter expression-holding type and would even wish to have had this on day one. Retrofitting
isless appealing. We document a similarity with regular expressions here where we, for better and worse, have lived
withouta regexppath data type forever and leave it to the executor to tell the user their pattern is invalid. Leaning
onthat 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.
This feels different from a documented difference in behavior as an implementation choice, like path regex vs. Spencer.
Inthis case, the expression is technically meaningless, but there’s never so much as an error thrown.
> Does the standard even have a separate type here or is that our implementation detail invention?
Sorry, separate type for what?
Best,
David
