Clarify truthy/falsy evaluation semantics for JSONPath conditions in Criterion Objects

[frankkilcommins]

This topic was originally discussed in slack

The Arazzo specification allows for a condition to be expressed using JSONPath via the Criterion Object, but it does not currently define how the result of such expressions should be interpreted.

The general expectation is that conditions act as truthy/falsy constructs, but without explicit guidance, tooling must infer whether a condition has passed or failed based on assumptions about the evaluation result.

A common example used in the spec, and existing documentation:

- context: $response.body
  condition: $[?count(@.pets) > 0]
  type: jsonpath

According to RFC 9535, the expression used above is valid and returns a nodelist, which may be empty or contain one or more nodes. It does not return a boolean.

The expected behaviour in Arazzo for the above condition:

• If the result is a non-empty nodelist, the condition passes
• If the result is an empty nodelist, the condition fails

However, this behaviour is currently not defined in the specification. There is:

• No normative language around evaluating the result of a JSONPath expression
• No mention of converting a NodesType to pass/fail using RFC 9535’s type conversion semantics (e.g. Section 2.4.2)

This omission leaves tooling authors guessing, potentially leading to inconsistent or non-compliant behavior across implementations.

In contrast, XPath-based conditions do allow for valid expressions that return boolean values directly (e.g., count(/root/pets/*) > 0 could be used in the example for an equivalent XML response), making them more predictable for condition evaluation.