Well-Typedness of Function Expressions

[jg-rp]

Using function extensions currently defined by the standard, it's not possible to test some valid JSONPath queries. Specifically, no standard function extension returns a NodesType result, and no standard function extension accepts a LogicalType parameter.

For example, if func() were a function extension defined to accept a LogicalType parameter and return a LogicalType result, the following queries would be valid.

• $[func(@.a == @.b)]
• $[func(@.*)] (section 2.4.2 - Type Conversion)

The table in section 2.4.9 contains more combinations of parameter/result types that can't currently be tested.

The question is, should this test suite define non-standard function extensions in order to cover these cases?

If so, how could that be done? And should we attempt to maintain backwards compatibility for dependants that don't implement non-standard function extensions (that is, keep such test cases out of cts.json)?

See also the conversation on PR #51, which attempted to add a query similar to the first example above.

[glyn]

The question is, should this test suite define non-standard function extensions in order to cover these cases?

I don't think it should because presumably that would mean implementations would need to implement those non-standard extensions in order to pass the test suite.

I suppose one way round this would be to register standard function extensions for the purpose of testing.

[f3ath]

FWIW my implementation supports custom functions and provides a few non-standard ones as examples and for testing purposes, including

• siblings() which is (NodesType) -> NodesType
• xor() which is (LogicalType, LogicalType) -> LogicalType