Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 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 ?  ,    , 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 ] : 
 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 . 
 Please approve if your concerns are now addressed . 
 I 've started the next batch of predicate improvements in draft PR 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 " 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 . 
 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 does n'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 do n't have a problem with requiring parentheses instead of creating an elaborate precedence hierarchy ( or at least partially instead of ) . I also do n'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 do n'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 wo n't help parser generators ... 
 The does n'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 is n’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 .  ,
Paragraph (version A):
Explicit boolean type conversion is done by the not operator "neg-
op".