[Bug 26453] [xp3.1] Lowest common supertype

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26453

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
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...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 17 September 2014 08:13:12 UTC