Draft: draft-ietf-jsonpath-base

Commentary: After thinking a while about comparing structured types , I now see no problem to support equality of them . I agree to handling them is straightforward : also see ... not exactly , what we want though . We need to be clear about order ... ! Containables may be defined on exactly that comparison rule . I believe , we need to add objects here again . Also we need to discuss subsets . Once having agreement about handling that edge cases ( maybe there are more ) , we might add it to the spec . Btw . : JavaScript resolves all comparisons above to , since objects are equal only , if they are referencing the same object ( no deep equals ) . 
 Comments inline . ordering . surprise and so is likely to cause confusion . Also I am not aware of any precedent for such conflation in mathematics or programming language semantics . [ 1,2 ] in [ [ 1,2 ] ] // structured value membership Also , we need to discuss ordering of arrays . For example : [ 1,2 ] in [ [ 2,1 ] ] should be false , if we agree that [ 1,2 ] ! = [ 2,1 ] . I do n't think we should conflate membership and subset . Since " in " has a stronger connotation of membership than subset , I do n't think we can easily define " in " with an object on the right hand side . Note also that there is n't yet a notation for a mathematical " maplet " , but if we represented it as a pair , e.g. ( ' x',1 ) , then we could test membership of objects thus : ( ' x',1 ) in { x:1 } ( However , I do n't think this is worth the cost of increased complexity of the spec . ) 
 I totally support a decision to : not dealing with subsets restrict the rhs to arrays only with contain - expr 's . 
 We decided not to have " in " , so this is now closed / revisit - after - base - done . 
 [ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be ( Do not use the term " whitespace " any more . ) Task " T1 " in the document 
 and 
 While this may be a bit premature as long as we do n't know what the rhs of contain - expr should be , it is missing its lhs . What is in the container ? 
 Oh , and the same with : 
 Well ... good point . Starting with these examples : lhs is restricted to a primitive value ( possibly only number and string ) . lhs holding a complex value will fail , i.e. no selection occurs . rhs must be resolved to a complex value ( array or object ) . rhs holding a simple value will fail , i.e. no selection occurs . Given this we have something like this ... ... as a starting proposal . 
 ( From 2021 - 09 - 17 interim :) So we would have syntax for array literals composed of primitive values only ( subset of  array literals ) ; other  array literals cause a syntax error . ( Empty array literals should be allowed to simplify code generation . ) A LHS evaluating to a complex value would not match . The path on the RHS may also yield an array , we would match against every single element of that like we would match against a literal array . Example : tending towards consensus on : if $ .colors is an array of structured values , is a single structured value ? only match primitive values from the LHS ( counterintuitive ! ? ) = [ 128 , 255 , 17 ] no selection even if = [ [ 128 , 255 , 17 ] , [ 1 , 2 , 3 ] ] ( we can not avoid structured data to turn up in a query , but we do n't match ) Avoid deep equals ! ( We already avoid it in simple comparisons . ) 
 Reminder : lhs of ... From to as a proposal . 
 Fixed in ( Still needs resolution of to become active . ) 
 Let 's merge this so we have a better base for discussion .
Paragraph (version A):
A member or element value by itself is _falsy_ only, if it does
not exist.  Otherwise it is _truthy_, resulting in its value.  To
be more specific explicit comparisons are necessary.  This
existence test -- as an exception of the general rule -- also
works with complex values.
Paragraph (version A):
Containment tests work with arrays and objects.
Paragraph (version B):
A member or element value by itself is _falsy_ only, if it does
not exist.  Otherwise it is _truthy_, resulting in its value.  To
be more specific explicit comparisons are necessary.  This
existence test -- as an exception of the general rule -- also
works with structured values.
Paragraph (version B):
The value of the first operand ("containable") of a "contain-expr"
is compared to every single element of the RHS "container".  In
case of a match a selection occurs.  Containment tests -- like
comparisons -- are restricted to primitive values.  So even if a
structured "containable" value is equal to a certain structured
value in "container", no selection is done.
Paragraph (version B):
The value of the second operand ("container") of a "contain-expr"
needs to be resolved to an array.  Otherwise nothing is selected.