Draft: draft-ietf-jsonpath-base

Commentary: Fixes 
 Thanks for your comments and I feel I should explain . The current draft defines the orderings and using the same text . For strings , the text talks about " less than " but not " greater than " . So the current text implicitly assumes that for strings and , if and only if . Non - mathematicians would tend to say this is patently obvious . But this PR avoids that assumption by only defining using the same text and then defining in terms of . However , I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other . So my question is : is the current draft text sufficiently precise ? If not , I 'll rework this PR to make it more precise . ( When I started out doing that , it began to get quite wordy , so I changed tack . ) 
 Despite the fact , that  's approach is mathematically clean , I would favour the symmetric approach by defining , , . I am quite sure , that nobody will cry " redundancy " then . 
 Yes . Is that a problem ? comes before ... 
 Actually , on the symmetry point , we were comfortable defining in terms of and that was asymmetric . 
 In what system of mathematics are operations ordered ? This is completely arbitrary . I 'm not convinced this needs to change . I prefer defining both and . And for symmetry , I 'd change strings to match . 
 Applying editorial discretion here . Merging . 
 The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another . That 's fine for , but : for it effectively assumes is fixed ( i.e. that for strings and if or ) for and it leaves quite a lot to the reader 's imagination . Once we 've settled on , the above should be addressed . ~We should also adopt a similar approach for ordered comparisons ( < , ) of arrays if is adopted.~ ( It was n't . ) ( I labelled this issue as because I do n't believe it will change the intended semantics in either case . ) 
 I propose to let land before addressing this issue . 
 I personally prefer the previous version , with standalone definitions , but think this is a matter of editorial discretion . I agree with  . It 's fine and correct to define in terms of other operators , but I feel and should both be equally defined . Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined . This PR is exactly the right way to do this .
Paragraph (version A):
The comparison operators "==", "<", and ">" are defined first and
then these are used to define "!=", "<=", and ">=".
Paragraph (version B):
The comparison operators "==" and "<" are defined first and then
these are used to define "!=", "<=", ">", and ">=".
Paragraph (version A):
a comparison using either of the operators "<" or ">" yields
false.
Paragraph (version B):
a comparison using the operator "<" yields false.
Paragraph (version A):
Note that comparisons using either of the operators "<" or ">" yield
false if either value being compared is an object, array, boolean, or
"null".
Paragraph (version B):
Note that comparisons using the operator "<" yield false if either
value being compared is an object, array, boolean, or "null".
Paragraph (version A):
The comparison "a >= b" yields true if and only if "a > b" yields
true or "a == b" yields true.
Paragraph (version B):
The comparison "a > b" yields true if and only if "b < a" yields
true.
Paragraph (version B):
The comparison "a >= b" yields true if and only if "b < a" yields
true or "a == b" yields true.