Draft: draft-ietf-jsonpath-base

Commentary:  comparisons Make regex operator conform to Perl etc . Add operator precedence table Fixes Fixes Fixes 
 I think having the precedence table now , above remark is obsolete . 
 Thanks I raised to remove that remark . 
 Perl introduced as ( where regexp actually could be a substitute operator etc . ) . Ruby generalized this to and . (  , JavaScript , Python , PowerShell do n'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 . Originally posted by in 
 Introducing an operator precedence table will help us comunicate what we are trying to achieve precedence - wise in the ABNF syntax . Originally posted by in 
 Here is a first version ... taken from 
 Thanks for that I suggest we combine the third and fourth rows and give and the same precedence as the other comparison operators as I do n't think there is a situation where their relative precedence is necessary . Also , having a separate row for and gives the impression we want to entertain expressions such as : and which I 'd prefer to avoid 
 Yes ... so ... 
 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 " 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 ... ) .  ,  , Python , PowerShell do n'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 . 
 This looks good . Just some curiosity questions from me .
Paragraph (version B):
The following table lists filter expression operators in order of
precedence from highest (binds most tightly) to lowest (binds least
tightly).