Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 Usually , existence could be asked in the form " is there any ... " . We restrict exist - expr to singular paths , though . Do we really want to make this restriction ? 
 I 'm trying to think how this would be done practically . All the examples for existence testing are in the form ( as you mention ) . What sorts of plural paths are you suggesting could also test for existence ? The only one I can think of would be which I suppose could return any non - empty objects . 
 -- which top level elements have sub - elements with a fallback member ? 
 It 's not obvious to me what you 're expecting here . Consider If we try with   , an implementation that evaluates as a test for existence , and supports arbitrary JSONPath expressions in filter predicates , we obtain With Jayway semantics , all the evaluations of have to return true for to be accepted . 
 yes , good question . Note Jayway 's logical treatment of existence of all members of an empty set . Evaluating against yields : 
 Obviously , if the path is no longer singular , there needs to be a definition if this is a ∀ for - all ( as in Jayway ) or an ∃ exists ( as I would have expected from the name ) . 
 I see no problem with this . I would also expect this to be an " any exists " operation . Framed more verbosely , the query says " find all children of the root array for which returns a non - empty set . " This interpretation would return the first two sub - arrays . 
 Just to follow up with a comparison with JSONPath , which is another of the dozen implementations in the JSONPath Comparisons that evaluate as a test for existence . Of these dozen implementations , Jayway and Newtonsoft are clearly the most important .   is likely the most widely used of all implementations , and is incorporated in Oracle enterprise API 's . Newtonsoft JSON.Net shows 2 billion downloads on NuGet . Given and query Newtonsoft JSONPath returns no results . However , given , to my eye , the more natural query Newtonsoft JSONPath returns Jayway , in contrast , when given returns everything , 
 ( Newtonsoft is losing importance as .Net 's built - in JSON support continues to grow . Newtonsoft 's download count is due to it being available for a couple decades . It 's not a good metric to convey current state . ) 
 All the more impressive that Newtonsoft 's JSONPath is more expressive than the Committee 's attempts :-) At least with supporting a natural query that returns preferred result . Best regards ,    agree that Newtonsoft 's .Net JSONPath is n't as important as    , which is older . I do n't think JSONPath ever achieved the popularity on .Net that Jayway did in  , where it got incorporated into Oracle enterprise API 's . In .Net , users were more likely , once the  was mapped into C # types , to use Microsoft technologies , notably LINQ , to query them . On Stack Overflow , it sometimes seems that   is JSONPath , to users , who rarely qualify their questions by mentioning the implementation , and to responders , who answer accordingly . For example , a recent questioner asked about the function , which Jayway has , but otherwise is not common . A responder replied referencing a Jayway online site . Neither questioner or responder specifically mentioned " Jayway " , but they obviously had a common frame of reference . 
 Currently , the only relative ( path we have is : That would need to be generalized for exist - expr . 
 I 've deleted my comment as it was nonsense ! ( Probably caused by thoughts of being termed a selector . ) 
 Let 's keep this issue open and revisit it as the spec firms up . This was agreed at the 2022 - 9 - 27 interim . 
 I will attempt to add a comparison project test as part of this . 
 Added : There is no calculated consensus among implementations . 
 Looks like a lot of them do either reject the syntax or otherwise fail to evaluate it , though . 
 I think that gives us freedom to define this feature the way we want . Compare filter selectors without the outer parentheses ( e.g. ) which I 'm sure most , if not all , existing implementations would reject with a syntax error . 
 I 'm happy with the textual changes . I 'd prefer or someone else look at the ABNF .
Paragraph (version A):
Comparisons are restricted to Singular Path values and primitive
values (that is, numbers, strings, "true", "false", and "null").
Paragraph (version B):
Comparisons are restricted to Singular Path values, each of which
selects at most one node, and primitive values (that is, numbers,
strings, "true", "false", and "null").
Paragraph (version A):
A singular path by itself in a Boolean context is an existence test
which yields true if the path selects a node and yields false if the
path does not select a node.  This existence test -- as an exception
to the general rule -- also works with nodes with structured values.
Paragraph (version B):
A path by itself in a Boolean context is an existence test which
yields true if the path selects at least one node and yields false if
the path does not select any nodes.
Paragraph (version B):
they work with arbitrary relative or absolute paths (not just
Singular Paths).
Paragraph (version B):
they work with paths that select structured values.