Add tests for top-level primitives

[Marcono1234]

Currently all tests seem to use either a JSON array or a JSON object as top-level value. However, since RFC 7159 (see appendix), and therefore also for the latest JSON RFC, primitive values are allowed at the top-level as well.

The goal is not to cover the contrived case where users intentionally query against a primitive top-level value, but rather that queries don't behave incorrectly for an unexpected top-level primitive.

The JSONPath standard does not seem to explicitly mention the behavior for top-level primitives, but the behavior seems to be implied by the general specified behavior for JSON values regardless of nesting level.

I assume the following is the desired behavior:

JSON	Path	Result	Comment
null	$	[null]	Section 2.2.2: No restrictions on the value type.
1	$	[1]	see above
1	$.*	[]	Section 2.3.2.2: Wildcard only works for arrays and objects.
1	$[*]	[]	see above
1	$..*	[]	see above; per section 2.5.2.2 .. can technically apply to primitive values as well ("visits the input node [...]"; no restrictions), but $.. on its own is not valid syntax
"test"	$[0]	[]	Section 2.3.3.2: Index only works for arrays.
"test"	$[1:3]	[]	Array slice only works for arrays.
true	$[?@]	[]	Section 2.3.5.2: Filter only works for arrays and objects.
"test"	$[?length(@) > 0]	[]	see above; in particular @ does not refer to the string value here

Maybe it would make sense to duplicate most of these tests for null and a non-null top-level value, in case there are libraries which treat a top-level JSON null specially (when they shouldn't?).

(please correct me if something is wrong or is missing a case)

[gregsdennis]

I think these would make a good addition to the suite.

Specifically, I would tests for

• root against all JSON types
• all selector types (index, name, shorthand name, slice, filter, and descendant versions of all of these) against all JSON types

I also would want to ensure that no other functionality is being tested. For example, use only simple filters like [?@] (no functions).

Remember, we're not testing for "no values are selected"; we're testing for "is the right thing selected," which for many of these means no values are selected, but not always.

[gregsdennis]

$[?length(@) > 0] - in particular @ does not refer to the string value here

[...] is the operation that checks for containers (rules out primitives). It's sufficient to show that the implementation handles $[?@] correctly. The above path run against primitive values doesn't add value to the suite.