Change:
Fixes URL
Thanks for the various comments. I've been busy with other things, but intend to come back before too long, absorb those comments, and push up some changes.
Yes. How is that "little response”? I’m still trying to parse what you mean by "This was asked earlier and received little response.”. What are you trying to say? Grüße, Carsten
Ok, so I pushed up some changes which attempt to address all the issues raised. Please see the individual commit logs for more detailed comments.
Maybe we want to add an [operator precedence table][1] into the text and try to make sure the grammar is somewhat congruence to that table. [1]: URL
Good idea, but I'd prefer to defer as I've got enough to deal with in this PR! It will also be even more valuable if we end up supporting arithmetic expressions...
Having an operator precedence table will help us understand what we are trying to do here. But I believe in incremental improvement, so completing this PR and then re-approaching it from the angle of the precedence table works for me.
NAME Please approve if your concerns are now addressed.
I've started the next batch of predicate improvements in draft PR URL which is based on this PR.
Currently, filter comparison require a path on the left hand side and a constant expression on the right hand side. This seems overly restrictive. We should generalise it to allow the opposite order as well as path to path comparisons and, for completeness, constant expression to constant expression comparisons. For example, the following comparisons should be valid:
Should be symmetric, too?
Did you mean (which is what we use in the current draft)? I think not because its operands have distinct types and it's probably easier to police restrictions and give good diagnostics if we keep asymmetric. For instance, with the current syntax: can fail with an error such as "NAME needs to be a regular expression literal", which is a bit easier to understand than something like "one side of ~= needs to be a regular expression literal". Having said that, other generalisations of may be worth it, such as allowing a string literal (rather than only a path) on the left hand side, for consistency with the above syntax for the other comparison operators, but even that could be give rise to confusion, e.g.:
Oops. It really should be . Perl introduced as (where regexp actually could be a substitute operator etc.). Ruby generalized this to and (actually, even more general...). Java, JavaScript, Python, PowerShell don't have an operator at all; this is all handled using method calls. So if we want to have syntax for regexp matching, we probably want to go with Perl's. We also need to discuss whether we need syntax for regexp literals. But this is maybe leading beyond this github issue.
When witing the current node represented by will be selected. So resulting in the same as . Is this really, what we want?
Anything else we might want? (I'm not sure we can write a syntax that only lets "meaningful" expressions through.)
Convinced ... you made the point.
The filter syntax currently requires predicates to be expressed in (something close to) disjunctive normal form (OR of ANDs), but this is likely to be inconvenient when the intention of the filter is expressed in a different way (e.g. as an AND or ORs or as a nested predicate with ANDs and ORs at various levels). The JSONPath comparison project doesn't yet test these more complex predicates, although some, possibly most, implementations allow them. The standard could allow arbitrarily structured predicates via syntax along these lines: For example, this would allow filters such as: and (where the semantics could, in line with mathematical convention and many programming languages, define to bind more tightly than ). Note: the comparison project's restricts the syntax so that brackets are required_ instead of making bind more tightly than . This is a clever approach but is probably not suitable for the standard because it is rather unconventional.
I don't have a problem with requiring parentheses instead of creating an elaborate precedence hierarchy (or at least partially instead of). I also don't have a problem with arbitrary nesting here.
For clarity, this is because is a multiplicative operation whereas is additive. Standard order of operations then apply. I don't know any programming language where this is reversed. I'm not opposed to requiring , however.
If the fact that binds more tightly than must be made explicite in the ABNF, it should be done. Using pairs of parentheses should be arbitrary.
Agreed. Is there a preferred way to specify operator precedence in ABNF? The examples I've seen use a textual ordered list which won't help parser generators...
The doesn't use ANBF, but it is pretty clear by using prose and a table. See section 12.4.2. There's also a bit more about associativity, but I figured this was enough.
Interesting. Does anyone know if ABNF parser generators infer operator precedence from the structure of the productions?
I would venture to say that is a near-universal property of BNF-based parser generators. Strictly speaking, BNF provides only a Boolean output: word is in language or it is not. But in reality, people use BNF for parsing, and build the parse tree along the structure of the BNF productions that was used for matching. That may be ambiguous even when the language created by the BNF isn’t, and that’s one reason why we have all these variants like LL(1) and LR(k) etc. The parse tree is then used to build an “abstract syntax tree”, ast, in many cases by attaching actions to the productions in the grammar. Grüße, Carsten

Discussion:
Containment tests work with arrays and objects. <del> Explicit boolean type conversion is done by the not operator "neg- op". </del> The behaviour of operators is consistent with the 'C'-family of programming languages.