Change:
Changes: Frame in terms of or Frame in terms of or Frame in terms of not Unify the structure of comparisons of absent values and singular values Fixes URL
... this is a significant improvement in Consistency and Simplicity. Thanks for your work.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
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.

Discussion:
3.4.7.2.2. <ins> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of <del> a comparison, the comparison yields true if and only if: </del> <ins> a comparison: </ins> <del> the comparison operator is "==", ">=" or "<=" and the other side of the comparison is also a path resulting in an empty nodelist, or </del> <ins> a comparison using the operator "==" yields true if and only if the comparison is between two paths each of which result in an empty nodelist. </ins> <del> the comparison operator is "!=" and the other side of the comparison is not also a path resulting in an empty nodelist. </del> <ins> a comparison using either of the operators "<" or ">" yields false. </ins> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value

for each of those names, the values associated with the name by the objects are equal. <del> a comparison using the operator "!=" yields true if and only if the comparison is not between equal values of the same type. a comparison using one of the operators "<", "<=", ">", or ">=" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> a comparison using either of the operators "<" or ">" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to

first string compares less than the remainder of the second string. <del> Note that comparisons using any of the operators "<", "<=", ">", or ">=" yield false if either value being compared is an object, array, boolean, or "null". </del> <ins> Note that comparisons using either of the operators "<" or ">" yield false if either value being compared is an object, array, boolean, or "null". "!=", "<=" 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 "a > b" yields true or "a == b" yields true. </ins> 3.4.7.2.2.1.