Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 From it was stated that the current ABNF does n't require parentheses around the expression in a filter expression . The spec thus contains examples without them . Previous discussions had occurred around making them optional , but no decision came out of them that I can recall . The closest documented conversation I could find was by and the following comments which indicate that the parentheses are currently expected . To be clear , we should currently require , and disallow . The original blog post consistently uses them and never shows a filter expression selector without them . 
 I do n't have a strong opinion on this simplification , but one data point : The simplified grammar has been in the document since we ABNF grammar , i.e. , in draft - ietf - jsonpath - base-01 ( 2021 - 07 - 08 ) . The discussion was started in , 2021 - 04 - 30 . For me , the current ABNF is the status quo .. If we need to have a discussion here , let 's have it , but I 'm not interested in the " we have n't discussed this enough " angle -- this has been out in the document for 9 months . So if there are any technical arguments for requiring the parentheses , please add them here . 
 I am strongly voting for the simplified , backwards compatible notation with optional parentheses . 
 The PR that put in the ABNF ( which has never changed in substance with regard to requiring parentheses ): There is even a comment from you ( Greg ) on that ABNF snippet in that PR conversation , so you apparently reviewed it . ( Of course , you might have missed the simplification and there may be technical arguments against it -- let 's hear them . ) 
 Yes , looking back , I see point 4.1 in raised the topic , and the fact that it was n't discussed at all ( even though the original post said it should be discussed ) could have been interpreted as acceptance and agreement . Also , that PR you reference is massive . It 's easy to miss in the multitude of changes contained therein . I suspect this was something that was snuck in rather than agreed upon . Agreement requires discussion , and I see none . Personally , when I see , the looks as though it 's part of the expression . Having the parentheses , , better isolates the expression visually . This is not a problem of parsing , but one of the human element . 
 For the record , I was originally uncomfortable with the parentheses being optional , but I remember this being discussed at a meeting quite a while ago and I was persuaded at that time that the current approach is reasonable . Perhaps that discussion was n't highlighted in the minutes . I think we should stay as we are . 
 I know you already commented to the contrary , but your original post has this to say : I think this is pretty indicative that parentheses should be included as part of the required syntax . Taking this stance also aligns with our preference to accommodate existing implementations . While we say that this is a backward compatible change , it may not be . For instance , my parser wo n't recognize a filter selector without the parentheses . I expect many other existing implementations will be the same . 
 At today 's meeting I took an action to write a comparison project test for a filter without parentheses . It turns out there is one already -- -- and the consensus among implementations is " Not supported " . 
 Hardly indicative . Original Goessner JsonPath used JavaScript for evaluating filter expressions , I imagine that requiring the outer parentheses was just to provide a pragmatic way to delimit the JavaScript part , original Goessner JsonPath was not responsible for parsing that part . That consideration no longer applies when the syntax of filter expressions is defined in the JSONPath specification , mandatory outer parentheses no longer serve any purpose . Be real :-) The spec in its current form is incompatible to a lessor or greater extent with all existing JSONPath implementations . 
 I still vote for the lean syntax with optional parentheses in filter expressions . Old queries ( having parentheses ) can be handled by ' old ' and ' new ' implementations without problems ( backward compatibility ) . We do n't break old ' query code ' . New queries ( no parentheses ) can be treated by ' new ' implementations only . This is the same behavior compared with regular expressions in filters , not being understood by old implementations . Thanks for  also making that point . Am 26.04.2022 um 19:26 schrieb   : 
 My issue is n't that existing paths can be handled by new implementations ( what we 're calling " backward comparability " ) , but rather the inverse : new paths wo n't be handled by existing implementations ( " forward compatibility " ) . Users will complain that their paths , which do n't have parentheses , do n't work . Implementors will respond with , " You need parentheses , " and then users will be trained to use parentheses anyway . As it stands , most users are already trained to use parentheses because existing implementations require them . 
 Right . For new features we ca n't expect forward compatibility anyway . The discussion here was whether it is worth to reduce forward compatibility by admitting new syntax for existing , widely implemented features . And I grudgingly have to acknowledge that that is a different question . Actually , implementers will quickly fix that . Between competing implementations , there is a race to accept the largest amount of inputs ( within reason , i.e. , balancing it with the cost of implementing them ) . But , yes , query creators that care about widest compatibility will be trained to use the parentheses . ( For me , actually , having a feature that only new implementations can understand is a feature . So the expression will break on implementations that have n't been updated .  . And a nice canary . ) Yes , which is part of the reason why I still think we would better give up on forward compatibility here in favor of cleaning up the query language . But that is now a matter of taste , and I have to accept that there is a valid argument to the contrary . 
 I just do n't think it makes sense to go down this road . Users will understand that IETF JsonPath is just another take on the idea of JSONPath , an idea that took major forks from very early on . Any Stack Overflow question on JSONPath quickly establishes that the answers are generally implementation specific . 
 I 'm going to stop pushing this , but I would like to add this last comment .   has had several forward - incompatible changes over the years as well that I 've been fine with . But the difference between this and those is that   is already published and versioned . It 's easy to tell people , " As of version X , this feature works differently . " We 're not technically versioned as yet because we do n't really have a proper publication from which a full implementation can be built ( because we 're not done ) . It feels different to make this change for a 1.0 . But I 'll follow the team 's consensus . 
 Have you submitted an issue ? 
 No . I would add that the fact that they 're different does n't mean that they 're wrong , because languages like Python , JavaScript and C use different precedence orderings , particularly Python and JavaScript , see e.g. and , , and . My comment to was only about them being different . 
 please do ; I was n't aware they are different . ( Thanks for the pointers , very useful ! -- the C one is a copy of the XPath one , though , and I ca n't resolve the Python one . ) 
 All right , . 
 I 'm not sure what the big fuss about the precedences being different is . For the operations we have defined , all of these are largely equivalent . Some have variation in that comparisons are higher than equality , but I 'm not even sure under what circumstances that 'd be useful . Contrivingly , I could say as a shorthand for but that 's stretching things , IMO . I ca n't see that such a thing would be so useful that they 'd add it into the language . do you know why that split in precedence is defined ? 
 My own , personal view , is that it 's unrewarding to think about precedences , and uninteresting to spend any time at all on thinking about the implications of trying something different . That 's why my personal preference is to blindly follow what somebody else has already done , and not attempt anything new . I 'd like to assume that the authors of C and Python have thought about this , I do n't want to . So , when I implemented this , I followed C , except where C did n't have , I followed Perl , and ended up with . If like I had a strong preference that the comparison and equality operators belonged at the same level , I would have chosen another language to follow that did that , Python qualifies , and used that language as a model for all operators , except , which Python does n't have , and gone with Perl again for that . What I would n't do is is help myself to Python 's comparison and equality operators , but C 's logical not operator . As much as possible , I would want one model to base my implementation on . Daniel 
 very helpfull indeed . IIRC ... I took my first proposal of the precedence table from JavaScript ( MDN ) , which should follow    can not explain the fact now , why has the same precedence as . Maybe we also should follow C ... and also include an associativity column . oh , and insert following Perl . thanks 
 Why is there a difference ? I do n't see how the precedence chain we 've declared is any different than any of these languages . They 're semantically identical ! groups not comparison / equality ( what benefit is there to separating these ? ) logical and logical or All of the listed languages have this ordering . What is being discussed here ? 
 The current spec is silent about how is handled in many situations : is the result of applying the JSONPath to the  document ? is the result of applying the JSONPath to the  document ? The implies a node set with the single value . is the result of applying the JSONPath to the  document ? The implies a node set with the single value . is the result of applying the JSONPath to the  document ? Presumably a node set with the single value . is the result of applying the JSONPath to the  document ? Presumably a node set with the values and . is the result of applying the JSONPath to the  document ? is the result of applying the JSONPath to the  document ? is the result of applying the JSONPath to the  document ? The implies a node set with the single value . 
 To 1 . : Similar is To 6 . : To 7 . : 
 I have historically handles as a valid value ( contrary to most of .net ) separate from " undefined " or " missing . " As a result , I agree with these points . Specifically for [ 7 ] , this is an existence test . Since exists as a property in the object , that object would be returned . I believe we decided that existence testing does not consider falsiness .
Paragraph (version B):
Note that JSON "null" is treated the same as any other JSON value: it
is not taken to mean "undefined" or "missing".