Change:
The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further <del> errors can be raised during application of the query to a value. </del> <ins> errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of the query to a value. </ins> Obviously, an implementation can still fail when executing a JSONPath query, e.g., because of resource depletion, but this is not modeled

Discussion:
According to the current draft certain types, such as Booleans, are unordered: equality () and inequality () of values of these types are specified ordered comparisons (, , , and ) are specified to yield false for values of these types. However, is often understood the way it is read: "less than or equal to". Similarly for . If we could define as " or " and as " or ", then they could be easier to understand. With this change , for example, would yield true (whereas according to the current draft, it yields false). There is often an assumption that orderings are "total" or "linear" (see wikipedia for a ). A total order obeys the following laws: But according to the current draft, for example, and both yield false, contrary to the first of the above laws. This is because the ordering of Boolean values is not_ total. In the discussion at today's interim meeting (2022-08-17), it was suggested that the above laws could cause a problem for this issue. This does not appear to be the case because we are not dealing with total orders.
The above section about = is phrased in terms of total orders; I believe this is a POLS violation as most people will not think in terms of total orders here.
NAME Ok. That section isn't necessary: I was merely trying to capture the concern you expressed in the meeting. Please could you explain your concern with the above proposal (ignoring the "Total orders" section)?
Note to self: to avoid delta clashes, I intend to wait for the following PRs to land or close before submitting a PR for this issue: [x] URL [x] URL
Note to self (and anyone else who finds mathematics helpful)... With the proposed change, for all including when is "absent", an object, an array, a boolean, or . Apart from that is just as in the current draft. Similarly for which can be dealt with similarly. The ordering in the current draft is almost a partial order. That is, the following are true for all , , : except that the reflexive axiom is not true if or are "absent", an object, an array, a boolean, or . When restricted to numbers or restricted to strings is a total order.

That is if and are both numbers or both strings, then in addition to the partial order axioms, the following is true: Note: is not a total order when restricted to arrays (if we decide to support for arrays), since, for example: The ordering in the current draft is a strict partial order: The of defines in terms of_ : The result is the same as in the current draft except that for all . So, for example, (where is "absent", since ), , and (where and are objects for which ). So is a partial order (without exception) and is still a total order when restricted to numbers or when restricted to strings.
NB. if URL lands, is false, but with the above proposal it would be true.