Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 All of the other functions we 've defined account for input types that they do n't expect , and they return in those cases . We should update to do so as well . 
 count ( ) has declared type OptionalNodesType for its Argument 1 . How would it get anything but that ? 
 includes as a potential value . 
 Yes . As in  , there is a weird alignment between ( ) and nil ... I 'm not even sure we need NodesType to have an " Optional " aspect . But if we do , I agree we have to say what count makes out of Nothing ( either 0 or Nothing ) , and shape the return type accordingly . 
 PR fixes this issue in terms of the current type system in which is represented by a non - empty nodelist and is represented by a ( path producing a)n empty nodelist . 
 My argument for a distinction ( related to ) . When we first started discussing path expressions ( , I think ) , we decided that was disallowed as a complete expression , e.g. . This was intended to disambiguate from being either an existence test or a check that the value in is ( e.g. ) . As a result of this decision , the literal was only valid as a ; that is , it can only be used with a comparison operator , and a path such as is syntactically invalid . It also allowed the path to return a node for even though the value that 's returned by is . Without this distinction , would return  , be evaluated as Test - false , and no node would be returned . This means that there must be some distinction between the result of and the literal , although the colloquial meaning for both is " true . " In the interim call , I gave the example that if these are the same , then should be valid . Here 's why . If is the same thing as the literal , then I can do substitution and a valid expression should result . Since is a valid expression , it is implied that is a valid expression by substituting back the other way . But the ABNF forbids such an expression , so we have a contradiction , which implies our original assumption ( " is the same thing as the literal " ) must have been wrong . Pedantically , the literal is just that : a literal . It 's no different than the literal . It should n't carry any meaning of truthiness behind it , but it is commonly used that way . In terms of our expressions , it should be used as a mere token . is asking if the value in is the JSON token . The comparison returns a " true " or " false " result , an actual boolean value rather than just the JSON token , which can then be interpreted as the final result of the expression , or used as an operand for a logical operator , which itself returns a boolean to be interpreted as the final result of the expression . 
 I also want to explore the idea of " lowering " a TestBoolean to a JSONBoolean so that it can be used in a comparison . This idea is that we can go from a TestBoolean " true"/"false " to the JSONBoolean / , respectively , but not the other direction . This does retrict the literals and from being used in a logical expression ( e.g. ) . However , if TestBoolean can be lowered to function as JSONBoolean , then can be lowered to and can be lowered to , still implying that is valid . I think the only recourse here is to keep them distinct ideas . 
 I agree there should be a clear distinction between JSON booleans and the truth values associated with and . I believe the WG consensus supports this , as does the spec . 
 Good . Progress . No . The spec does not support this . The spec says that a function which returns can be used in both and . But you just said above that there needs to be a distinction between these . See my response to in as to why can not represent JSON booleans . I do n't feel like making that argument again . 
 ( Please also see the discussion in and , which is quite useful to find the root cause of this disagreement . )
Paragraph (version B):
If the argument is "Nothing" (which corresponds to an empty
nodelist), the result is the value "0".