On Jul 8, 2024, at 12:05, David G. Johnston <david.g.johns...@gmail.com> wrote:
> 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. 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 the way 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, not that 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 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. This feels different from a documented difference in behavior as an implementation choice, like path regex vs. Spencer. In this 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
