I propose we make "lowest common supertype" a defined term and define it as follows:

Given two atomic types A and B, the lowest common supertype of A and B is the atomic type determined as follows:

* If A and B are derived from the same primitive type, then the lowest common ancestor of A and B in the tree formed by the itemType-subType relation over atomic types.

* If A and B are derived from different primitive types P and Q, and P is promotable to Q, then Q (or vice-versa, if Q is promotable to P, then P). The only type pairs that are promotable in this way are decimal to float, float to double, decimal to double, and anyURI to string.

* If A and B are derived from different primitive types P and Q, and P is not promotable to Q and Q is not promotable to P, then xs:anyAtomicType.

A couple of additions:

Rule 0: if either A or B is xs:anyAtomicType, then xs:anyAtomicType

Rule N: having defined LCST(A, B), the LCST of a set of (more than two) atomic types A1, A2, .... An is LCST(A1, LCST(A2...An)).

Having define what we mean by LCST, I would really like to change the way it is used in F+O. It is currently used only by min() and max(), in the following rule:

Numeric and xs:anyURI values are converted to the least common type reachable by a combination of type promotion and subtype substitution. See Section B.1 Type Promotion XP30 and Section B.2 Operator Mapping XP30.

Note that only numeric and anyURI values are converted. If the items in the sequence are a mix of xs:positiveInteger and xs:unsignedShort, then they are all converted to xs:nonNegativeInteger, but if you have a mix of xs:IDREF and xs:ID, they are not converted to xs:NCName (even if there are also xs:anyURI values present in the sequence, which under this rule are converted to xs:string). Frankly, this is so weird that I find it hard to believe anyone implements it: especially as it is almost impossible to test that this is what is actually done; certainly there are no tests for the edge cases.

I propose to change the rule as follows:

* Call the input sequence after atomization and conversion of xs:untypedAtomic to xs:double C.

* if the values in C are all of the same primitive type, then the returned value is one of the values in C, without further conversion

* if the values in C are of more than one primitive type, and these types are mutually comparable by virtue of type promotion, then the returned value is one of the values in C, converted to the primitive type that is the LCST of the types present in C.

What changes? If you have a sequence that is a mix of xs:positiveInteger and xs:unsignedShort, you now have a guarantee that the result will be either an xs:positiveInteger or an xs:unsignedShort. Previously you only had a guarantee that it would be an xs:nonNegativeInteger. Your implementation might have given you an xs:positiveInteger (it was allowed to do so, but not required to do so). So in simplifying the rules, I believe we are actually 100% compatible.

If anyone doesn't believe this is an improvement, then I threaten to write some tests for the edge cases under the current rule and watch implementations break...

The only place in XPath where the concept of lowest/least common supertype is used is in value comparisons:

"Next, if possible, the two operands are converted to their least common type by a combination of type promotion and subtype substitution. For example, if the operands are of type hatsize (derived from xs:integer) and shoesize (derived from xs:float), their least common type is xs:float."

This rule is unnecessarily complicated. We could simplify it to:

"Next, if the types of the two operands are derived from different primitive types P and Q, and if P can be promoted to Q, then the operand of type P is cast to type Q."

Conversion to the LCST within the type hierarchy simply isn't necessary, because it has no effect on any subsequent operation.

In XQuery, LCST is also used in the definition of "order by":

The ordering is performed in the least common type that has a gt operator.

Again, this can be simplified. We only need to do conversions if different primitive types are involved.

Conclusion: all uses of "least common type reachable by a combination of subtype substitution and type promotion" can actually be reduced to "least common type reachable by type promotion".

The WG decided to go ahead with these changes (comments 3, 4, and 5).

The changes in comment 3 (min/max, F+O) have been applied. I decided to describe the effect of type promotion by enumerating the cases rather than relying on a concept of least common type.

Mike Kay suggests I follow the lead of min and max in F&O.

Confirmed that this change has been applied (to both affected specs).