2.3. Selectors
2.3. Selectors
Selectors appear only inside child segments (Section 2.5.1) and descendant segments (Section 2.5.2).
A selector produces a nodelist consisting of zero or more children of the input value.
There are various kinds of selectors that produce children of objects, children of arrays, or children of either objects or arrays.
selector = name-selector /
wildcard-selector /
slice-selector /
index-selector /
filter-selector
The syntax and semantics of each kind of selector are defined below.
2.3.1. Name Selector
2.3.1.1. Syntax
A name selector '
In contrast to JSON, the JSONPath syntax allows strings to be enclosed in single or double quotes.
name-selector = string-literal
string-literal = %x22 *double-quoted %x22 / ; "string"
%x27 *single-quoted %x27 ; 'string'
double-quoted = unescaped /
%x27 / ; '
ESC %x22 / ; \"
ESC escapable
single-quoted = unescaped /
%x22 / ; "
ESC %x27 / ; \'
ESC escapable
ESC = %x5C ; \ backslash
unescaped = %x20-21 / ; see RFC 8259
; omit 0x22 "
%x23-26 /
; omit 0x27 '
%x28-5B /
; omit 0x5C \
%x5D-D7FF /
; skip surrogate code points
%xE000-10FFFF
escapable = %x62 / ; b BS backspace U+0008
%x66 / ; f FF form feed U+000C
%x6E / ; n LF line feed U+000A
%x72 / ; r CR carriage return U+000D
%x74 / ; t HT horizontal tab U+0009
"/" / ; / slash (solidus) U+002F
"\" / ; \ backslash (reverse solidus) U+005C
(%x75 hexchar) ; uXXXX U+XXXX
hexchar = non-surrogate /
(high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Notes:
- Double-quoted strings follow the JSON string syntax (Section 7 of
[RFC8259]); single-quoted strings follow an analogous pattern. No attempt was made to improve on this syntax, so if it is desired to escape characters with scalar values above 0xFFFF, such as U+1F041 ("🁁", DOMINO TILE HORIZONTAL-02-02), they need to be represented by a pair of surrogate escapes ("\uD83C\uDC41" in this case).
- Alphabetic characters in quoted strings are case-insensitive in
ABNF, so each of the hexadecimal digits within \u escapes (as specified in rules referenced by hexchar) can be either lowercase or uppercase, while the u in \u needs to be lowercase (indicated as %x75).
2.3.1.2. Semantics
A name-selector string MUST be converted to a member name M by removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as shown in Table 4:
| Escape Sequence | Unicode Character | Description |
|---|---|---|
| \b | U+0008 | BS backspace |
| \t | U+0009 | HT horizontal tab |
| \n | U+000A | LF line feed |
| \f | U+000C | FF form feed |
| \r | U+000D | CR carriage return |
| " | U+0022 | quotation mark |
| ' | U+0027 | apostrophe |
| / | U+002F | slash (solidus) |
| \ | U+005C | backslash (reverse |
| solidus) | ||
| \uXXXX | see | hexadecimal escape |
| Section 2.3.1.1 |
Table 4: Escape Sequence Replacements
Applying the name-selector to an object node selects a member value whose name equals the member name M or selects nothing if there is no such member value. Nothing is selected from a value that is not an object.
Note: Processing the name selector requires comparing the member name string M with member name strings in the JSON to which the selector is being applied. Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to either the member name string M from the JSONPath or the member name strings in the JSON prior to comparison.
2.3.1.3. Examples
JSON:
{
"o": {"j j": {"k.k": 3}},
"'": {"@": 2}
}
Queries:
The examples in Table 5 show the name selector in use by child segments.
| Query | Result | Result Paths | Comment |
|---|---|---|---|
| $.o['j j'] | {"k.k": | $['o']['j j'] | Named |
| 3} | value in | ||
| a nested | |||
| object | |||
| $.o['j j']['k.k'] | 3 | $['o']['j j']['k.k'] | Nesting |
| further | |||
| down | |||
| $.o["j j"]["k.k"] | 3 | $['o']['j j']['k.k'] | Different |
| delimiter | |||
| in the | |||
| query, | |||
| unchanged | |||
| Normalized | |||
| Path | |||
| $["'"]["@"] | 2 | $[''']['@'] | Unusual |
| member | |||
| names |
Table 5: Name Selector Examples
2.3.2. Wildcard Selector
2.3.2.1. Syntax
The wildcard selector consists of an asterisk.
wildcard-selector = "*"
2.3.2.2. Semantics
A wildcard selector selects the nodes of all children of an object or array. The order in which the children of an object appear in the resultant nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist.
Note that the children of an object are its member values, not its member names.
The wildcard selector selects nothing from a primitive JSON value (that is, a number, a string, true, false, or null).
2.3.2.3. Examples
JSON:
{
"o": {"j": 1, "k": 2},
"a": [5, 3]
}
Queries:
The examples in Table 6 show the wildcard selector in use by a child segment.
| Query | Result | Result | Comment |
|---|---|---|---|
| Paths | |||
| $[*] | {"j": 1, | $['o'] | Object values |
| "k": 2} | $['a'] | ||
| [5, 3] | |||
| $.o[*] | 1 | $['o']['j'] | Object values |
| 2 | $['o']['k'] | ||
| $.o[*] | 2 | $['o']['k'] | Alternative |
| 1 | $['o']['j'] | result | |
| $.o[*, | 1 | $['o']['j'] | Non-deterministic |
| *] | 2 | $['o']['k'] | ordering |
| 2 | $['o']['k'] | ||
| 1 | $['o']['j'] | ||
| $.a[*] | 5 | $['a'][0] | Array members |
| 3 | $['a'][1] |
Table 6: Wildcard Selector Examples
The example above with the query $.o[*, *] shows that the wildcard selector may produce nodelists in distinct orders each time it appears in the child segment when it is applied to an object node with two or more members (but not when it is applied to object nodes with fewer than two members or to array nodes).
2.3.3. Index Selector
2.3.3.1. Syntax
An index selector <index> matches at most one array element value.
index-selector = int ; decimal integer
int = "0" /
(["-"] DIGIT1 *DIGIT) ; - optional
DIGIT1 = %x31-39 ; 1-9 non-zero digit
Applying the numerical index-selector selects the corresponding element. JSONPath allows it to be negative (see Section 2.3.3.2).
To be valid, the index selector value MUST be in the I-JSON range of exact values (see Section 2.1).
Notes:
-
An index-selector is an integer (in base 10, as in JSON numbers).
-
As in JSON numbers, the syntax does not allow octal-like integers
with leading zeros, such as 01 or -01.
2.3.3.2. Semantics
A non-negative index-selector applied to an array selects an array element using a zero-based index. For example, the selector 0 selects the first, and the selector 4 selects the fifth element of a sufficiently long array. Nothing is selected, and it is not an error, if the index lies outside the range of the array. Nothing is selected from a value that is not an array.
A negative index-selector counts from the array end backwards, obtaining an equivalent non-negative index-selector by adding the length of the array to the negative index. For example, the selector -1 selects the last, and the selector -2 selects the penultimate element of an array with at least two elements. As with non-negative indexes, it is not an error if such an element does not exist; this simply means that no element is selected.
2.3.3.3. Examples
JSON:
["a","b"]
Queries:
The examples in Table 7 show the index selector in use by a child segment.
| Query | Result | Result Paths | Comment |
|---|---|---|---|
| $[1] | "b" | $[1] | Element of array |
| $[-2] | "a" | $[0] | Element of array, from the end |
Table 7: Index Selector Examples
2.3.4. Array Slice Selector
2.3.4.1. Syntax
The array slice selector has the form <start>:
slice-selector = [start S] ":" S [end S] [":" [S step ]]
start = int ; included in selection end = int ; not included in selection step = int ; default: 1
The slice selector consists of three optional decimal integers separated by colons. The second colon can be omitted when the third integer is omitted.
To be valid, the integers provided MUST be in the I-JSON range of exact values (see Section 2.1).
2.3.4.2. Semantics
The slice selector was inspired by the slice operator that was proposed for ECMAScript 4 (ES4), which was never released, and that of Python.
2.3.4.2.1. Informal Introduction
This section is informative.
Array slicing is inspired by the behavior of the Array.prototype.slice method of the JavaScript language, as defined by the ECMA-262 standard [ECMA-262], with the addition of the step parameter, which is inspired by the Python slice expression.
The array slice expression start:end:step selects elements at indices starting at start, incrementing by step, and ending with end (which is itself excluded). So, for example, the expression 1:3 (where step defaults to 1) selects elements with indices 1 and 2 (in that order), whereas 1:5:2 selects elements with indices 1 and 3.
When step is negative, elements are selected in reverse order. Thus, for example, 5:1:-2 selects elements with indices 5 and 3 (in that order), and ::-1 selects all the elements of an array in reverse order.
When step is 0, no elements are selected. (This is the one case that differs from the behavior of Python, which raises an error in this case.)
The following section specifies the behavior fully, without depending on JavaScript or Python behavior.
2.3.4.2.2. Normative Semantics
A slice expression selects a subset of the elements of the input array in the same order as the array or the reverse order, depending on the sign of the step parameter. It selects no nodes from a node that is not an array.
A slice is defined by the two slice parameters, start and end, and an iteration delta, step. Each of these parameters is optional. In the rest of this section, len denotes the length of the input array.
The default value for step is 1. The default values for start and end depend on the sign of step, as shown in Table 8.
| Condition | start | end |
|---|---|---|
| step >= 0 | 0 | len |
| step < 0 | len - 1 | -len - 1 |
Table 8: Default Array Slice start and end Values
Slice expression parameters start and end are not directly usable as slice bounds and must first be normalized. Normalization for this purpose is defined as:
FUNCTION Normalize(i, len): IF i >= 0 THEN RETURN i ELSE RETURN len + i END IF
The result of the array index expression i applied to an array of length len is the result of the array slicing expression Normalize(i, len):Normalize(i, len)+1:1.
Slice expression parameters start and end are used to derive slice bounds lower and upper. The direction of the iteration, defined by the sign of step, determines which of the parameters is the lower bound and which is the upper bound:
FUNCTION Bounds(start, end, step, len): n_start = Normalize(start, len) n_end = Normalize(end, len)
IF step >= 0 THEN lower = MIN(MAX(n_start, 0), len) upper = MIN(MAX(n_end, 0), len) ELSE upper = MIN(MAX(n_start, -1), len-1) lower = MIN(MAX(n_end, -1), len-1) END IF
RETURN (lower, upper)
The slice expression selects elements with indices between the lower and upper bounds. In the following pseudocode, a(i) is the i+1th element of the array a (i.e., a(0) is the first element, a(1) the second, and so forth).
IF step > 0 THEN
i = lower WHILE i < upper: SELECT a(i) i = i + step END WHILE
ELSE if step < 0 THEN
i = upper WHILE lower < i: SELECT a(i) i = i + step END WHILE
END IF
When step = 0, no elements are selected, and the result array is empty.
2.3.4.3. Examples
JSON:
["a", "b", "c", "d", "e", "f", "g"]
Queries:
The examples in Table 9 show the array slice selector in use by a child segment.
| Query | Result | Result | Comment |
|---|---|---|---|
| Paths | |||
| $[1:3] | "b" | $[1] | Slice |
| "c" | $[2] | with | |
| default | |||
| step | |||
| $[5:] | "f" | $[5] | Slice |
| "g" | $[6] | with no | |
| end | |||
| index | |||
| $[1:5:2] | "b" | $[1] | Slice |
| "d" | $[3] | with | |
| step 2 | |||
| $[5:1:-2] | "f" | $[5] | Slice |
| "d" | $[3] | with | |
| negative | |||
| step | |||
| $[::-1] | "g" | $[6] | Slice in |
| "f" | $[5] | reverse | |
| "e" | $[4] | order | |
| "d" | $[3] | ||
| "c" | $[2] | ||
| "b" | $[1] | ||
| "a" | $[0] |
Table 9: Array Slice Selector Examples
2.3.5. Filter Selector
Filter selectors are used to iterate over the elements or members of structured values, i.e., JSON arrays and objects. The structured values are identified in the nodelist offered by the child or descendant segment using the filter selector.
For each iteration (element/member), a logical expression (the filter expression) is evaluated, which decides whether the node of the element/member is selected. (While a logical expression evaluates to what mathematically is a Boolean value, this specification uses the term logical to maintain a distinction from the Boolean values that JSON can represent.)
During the iteration process, the filter expression receives the node of each array element or object member value of the structured value being filtered; this element or member value is then known as the current node.
The current node can be used as the start of one or more JSONPath queries in subexpressions of the filter expression, notated via the current-node-identifier @. Each JSONPath query can be used either for testing existence of a result of the query, for obtaining a specific JSON value resulting from that query that can then be used in a comparison, or as a function argument.
Filter selectors may use function extensions, which are covered in Section 2.4. Within the logical expression for a filter selector, function expressions can be used to operate on nodelists and values. The set of available functions is extensible, with a number of functions predefined (see Section 2.4) and the ability to register further functions provided by the "Function Extensions" subregistry (Section 3.2). When a function is defined, it is given a unique name, and its return value and each of its parameters are given a declared type. The type system is limited in scope; its purpose is to express restrictions that, without functions, are implicit in the grammar of filter expressions. The type system also guides conversions (Section 2.4.2) that mimic the way different kinds of expressions are handled in the grammar when function expressions are not in use.
2.3.5.1. Syntax
The filter selector has the form ?<logical-expr>.
filter-selector = "?" S logical-expr
As the filter expression is composed of constituents free of side effects, the order of evaluation does not need to be (and is not) defined. Similarly, for conjunction (&&) and disjunction (||) (defined later), both a short-circuiting and a fully evaluating implementation will lead to the same result; both implementation strategies are therefore valid.
The current node is accessible via the current node identifier @. This identifier addresses the current node of the filter-selector that is directly enclosing the identifier. Note: Within nested filter-selectors, there is no syntax to address the current node of any other than the directly enclosing filter-selector (i.e., of filter-selectors enclosing the filter-selector that is directly enclosing the identifier).
Logical expressions offer the usual Boolean operators (|| for OR, && for AND, and ! for NOT). They have the normal semantics of Boolean algebra and obey its laws (for example, see [BOOLEAN-LAWS]). Parentheses MAY be used within logical-expr for grouping.
It is not required that logical-expr consist of a parenthesized expression (which was required in [JSONPath-orig]), although it can be, and the semantics are the same as without the parentheses.
logical-expr = logical-or-expr logical-or-expr = logical-and-expr *(S "||" S logical-and-expr) ; disjunction ; binds less tightly than conjunction logical-and-expr = basic-expr *(S "&&" S basic-expr) ; conjunction ; binds more tightly than disjunction
basic-expr = paren-expr /
comparison-expr /
test-expr
paren-expr = [logical-not-op S] "(" S logical-expr S ")" ; parenthesized expression logical-not-op = "!" ; logical NOT operator
A test expression either tests the existence of a node designated by an embedded query (see Section 2.3.5.2.1) or tests the result of a function expression (see Section 2.4). In the latter case, if the function's declared result type is LogicalType (see Section 2.4.1), it tests whether the result is LogicalTrue; if the function's declared result type is NodesType, it tests whether the result is non-empty. If the function's declared result type is ValueType, its use in a test expression is not well-typed (see Section 2.4.3).
test-expr = [logical-not-op S]
(filter-query / ; existence/non-existence
function-expr) ; LogicalType or NodesType
filter-query = rel-query / jsonpath-query
rel-query = current-node-identifier segments
current-node-identifier = "@"
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, true, false, and null). These can be obtained via literal values; singular queries, each of which selects at most one node, the value of which is then used; or function expressions (see Section 2.4) of type ValueType.
comparison-expr = comparable S comparison-op S comparable
literal = number / string-literal /
true / false / null
comparable = literal /
singular-query / ; singular query value
function-expr ; ValueType
comparison-op = "==" / "!=" /
"<=" / ">=" /
"<" / ">"
singular-query = rel-singular-query / abs-singular-query
rel-singular-query = current-node-identifier singular-query-segments
abs-singular-query = root-identifier singular-query-segments
singular-query-segments = *(S (name-segment / index-segment))
name-segment = ("[" name-selector "]") /
("." member-name-shorthand)
index-segment = "[" index-selector "]"
Literals can be notated in the way that is usual for JSON (with the extension that strings can use single-quote delimiters).
Note: Alphabetic characters in quoted strings are case-insensitive in ABNF, so within a floating point number, the ABNF expression "e" can be either the character 'e' or 'E'.
true, false, and null are lowercase only (case-sensitive).
number = (int / "-0") [ frac ] [ exp ] ; decimal number
frac = "." 1*DIGIT ; decimal fraction
exp = "e" [ "-" / "+" ] 1*DIGIT ; decimal exponent
true = %x74.72.75.65 ; true
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
Table 10 lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
| Precedence | Operator type | Syntax | ||
|---|---|---|---|---|
| 5 | Grouping | (...) | ||
| Function Expressions | name(...) | |||
| 4 | Logical NOT | ! | ||
| 3 | Relations | == != | ||
| < <= > >= | ||||
| 2 | Logical AND | && | ||
| 1 | Logical OR |
Table 10: Filter Expression Operator Precedence
2.3.5.2. Semantics
The filter selector works with arrays and objects exclusively. Its result is a list of (zero, one, multiple, or all) their array elements or member values, respectively. Applied to a primitive value, it selects nothing (and therefore does not contribute to the result of the filter selector).
In the resultant nodelist, children of an array are ordered by their position in the array. The order in which the children of an object (as opposed to an array) appear in the resultant nodelist is not stipulated, since JSON objects are unordered.
2.3.5.2.1. Existence Tests
A query by itself in a logical context is an existence test that yields true if the query selects at least one node and yields false if the query does not select any nodes.
Existence tests differ from comparisons in that:
- They work with arbitrary relative or absolute queries (not just
singular queries).
- They work with queries that select structured values.
To examine the value of a node selected by a query, an explicit comparison is necessary. For example, to test whether the node selected by the query @.foo has the value null, use @.foo == null (see Section 2.6) rather than the negated existence test [email protected] (which yields false if @.foo selects a node, regardless of the node's value). Similarly, @.foo == false yields true only if @.foo selects a node and the value of that node is false.
2.3.5.2.2. Comparisons
The comparison operators == and < are defined first, and then these are used to define !=, <=, >, and >=.
When either side of a comparison results in an empty nodelist or the special result Nothing (see Section 2.4.1):
- A comparison using the operator == yields true if and only the
other side also results in an empty nodelist or the special result Nothing.
- A comparison using the operator < yields false.
When any query or function expression on either side of a comparison results in a nodelist consisting of a single node, that side is replaced by the value of its node and then:
- A comparison using the operator == yields true if and only if the
comparison is between:
- numbers expected to interoperate, as per Section 2.2 of I-JSON
[RFC7493], that compare equal using normal mathematical equality,
- numbers, at least one of which is not expected to interoperate
as per I-JSON, where the numbers compare equal using an implementation-specific equality,
-
equal primitive values that are not numbers,
-
equal arrays, that is, arrays of the same length where each
element of the first array is equal to the corresponding element of the second array, or
- equal objects with no duplicate names, that is, where:
o both objects have the same collection of names (with no duplicates) and
o for each of those names, the values associated with the name by the objects are equal.
- A comparison using the operator < yields true if and only if the
comparison is between values that are both numbers or both strings and that satisfy the comparison:
- numbers expected to interoperate, as per Section 2.2 of I-JSON
[RFC7493], MUST compare using the normal mathematical ordering; numbers not expected to interoperate, as per I-JSON, MAY compare using an implementation-specific ordering,
-
the empty string compares less than any non-empty string, and
-
a non-empty string compares less than another non-empty string
if and only if the first string starts with a lower Unicode scalar value than the second string or if both strings start with the same Unicode scalar value and the remainder of the first string compares less than the remainder of the second string.
!=, <=, >, and >= are defined in terms of the other comparison operators. For any a and b:
- The comparison a != b yields true if and only if a == b yields
false.
- The comparison a <= b yields true if and only if a < b yields true
or a == b yields true.
-
The comparison a > b yields true if and only if b < a yields true.
-
The comparison a >= b yields true if and only if b < a yields true
or a == b yields true.
2.3.5.3. Examples
The first set of examples shows some comparison expressions and their result with a given JSON value as input.
JSON:
{
"obj": {"x": "y"},
"arr": [2, 3]
}
Comparisons:
| Comparison | Result | Comment |
|---|---|---|
| $.absent1 == $.absent2 | true | Empty nodelists |
| $.absent1 <= $.absent2 | true | == implies <= |
| $.absent == 'g' | false | Empty nodelist |
| $.absent1 != $.absent2 | false | Empty nodelists |
| $.absent != 'g' | true | Empty nodelist |
| 1 <= 2 | true | Numeric comparison |
| 1 > 2 | false | Numeric comparison |
| 13 == '13' | false | Type mismatch |
| 'a' <= 'b' | true | String comparison |
| 'a' > 'b' | false | String comparison |
| $.obj == $.arr | false | Type mismatch |
| $.obj != $.arr | true | Type mismatch |
| $.obj == $.obj | true | Object comparison |
| $.obj != $.obj | false | Object comparison |
| $.arr == $.arr | true | Array comparison |
| $.arr != $.arr | false | Array comparison |
| $.obj == 17 | false | Type mismatch |
| $.obj != 17 | true | Type mismatch |
| $.obj <= $.arr | false | Objects and arrays do |
| not offer < comparison | ||
| $.obj < $.arr | false | Objects and arrays do |
| not offer < comparison | ||
| $.obj <= $.obj | true | == implies <= |
| $.arr <= $.arr | true | == implies <= |
| 1 <= $.arr | false | Arrays do not offer < |
| comparison | ||
| 1 >= $.arr | false | Arrays do not offer < |
| comparison | ||
| 1 > $.arr | false | Arrays do not offer < |
| comparison | ||
| 1 < $.arr | false | Arrays do not offer < |
| comparison | ||
| true <= true | true | == implies <= |
| true > true | false | Booleans do not offer |
| < comparison |
Table 11: Comparison Examples
The second set of examples shows some complete JSONPath queries that make use of filter selectors and the results of evaluating these queries on a given JSON value as input. (Note: Two of the queries employ function extensions; please see Sections 2.4.6 and 2.4.7 for details about these.)
JSON:
{
"a": [3, 5, 1, 2, 4, 6,
{"b": "j"},
{"b": "k"},
{"b": {}},
{"b": "kilo"}
],
"o": {"p": 1, "q": 2, "r": 3, "s": 5, "t": {"u": 6}},
"e": "f"
}
Queries:
The examples in Table 12 show the filter selector in use by a child segment.
| Query | Result | Result Paths | Comment |
|---|---|---|---|
$.a[[email protected] == 'kilo'] | {"b": "kilo"} | $['a'][9] | Member value comparison |
$.a[?(@.b == 'kilo')] | {"b": "kilo"} | $['a'][9] | Equivalent query with enclosing parentheses |
$.a[?@>3.5] | 5, 4, 6 | $['a'][1], $['a'][4], $['a'][5] | Array value comparison |
$.a[[email protected]] | {"b": "j"}, {"b": "k"}, {"b": {}}, {"b": "kilo"} | $['a'][6], $['a'][7], $['a'][8], $['a'][9] | Array value existence |
$[?@.*] | array and object as in RFC | $['a'], $['o'] | Existence of non-singular queries |
$[?@[[email protected]]] | array as in RFC | $['a'] | Nested filters |
$.o[?@<3, ?@<3] | 1, 2 (order may vary) | $['o']['p'], $['o']['q'] | Non-deterministic ordering |
$.a[?@<2 || @.b == "k"] | 1, {"b": "k"} | $['a'][2], $['a'][7] | Array value logical OR |
$.a[?match(@.b, "[jk]")] | {"b": "j"}, {"b": "k"} | $['a'][6], $['a'][7] | Array value regular expression match |
$.a[?search(@.b, "[jk]")] | {"b": "j"}, {"b": "k"}, {"b": "kilo"} | $['a'][6], $['a'][7], $['a'][9] | Array value regular expression search |
$.o[?@>1 && @<4] | 2, 3 | $['o']['q'], $['o']['r'] | Object value logical AND |
$.o[?@>1 && @<4] (alternative) | 3, 2 | $['o']['r'], $['o']['q'] | Alternative result |
$.o[[email protected] || @.x] | {"u": 6} | $['o']['t'] | Object value logical OR |
$.a[[email protected] == $.x] | 3, 5, 1, 2, 4, 6 | $['a'][0] through $['a'][5] | Comparison of queries with no values |
$.a[?@ == @] | primitives and structured values as in RFC | $['a'][0] through $['a'][9] | Comparisons of primitive and of structured values |
Table 12: Filter Selector Examples
The example above with the query $.o[?@<3, ?@<3] shows that a filter selector may produce nodelists in distinct orders each time it appears in the child segment.