[Bug 5671] [FO] Type promotion in fn:min and fn:max

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5671





--- Comment #11 from Michael Dyck <jmdyck@ibiblio.org>  2008-07-19 09:56:20 ---
(In reply to comment #10)
>
> My reading of "least common type" was "least common type of all the items in
> the input sequence",

Ah, I see. Well, I think that's a sufficiently non-obvious reading that it
should be made explicit.

> I think that where it says $arg, it means $arg, and that it fails to capture
> the effective equivalence of xs:anyURI and xs:string.

Okay, so that's a mistake, right? Also, it fails to capture the exception for
xs:untypedAtomic (i.e., you can have xs:untypedAtomic values in $arg even
though they're neither numeric nor derived from a type for which the ge
operator is defined).

Is it intended that $collation be ignored for comparison of xs:anyURI values?

> >It's odd that we would require values of two subtypes of xs:integer to be
> converted to a common type (because they're numeric values), but not
> require values of two subtypes of (say) xs:date to be converted to a common
> type. Wouldn't it be correct to say that *all* values are converted to a
> common type, not just numerics and xs:anyURI?
> 
> Yes, it's a bit odd, but not odd enough to require a 1.0 change that will
> impact existing implementations.

I'm not clear on how it would affect an existing implementation. If (for the
example above) an implementation returns a subtype-of-date value that hasn't
been converted to the common type, that would still be conformant, under the
interpretation you gave in Comment #3.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 19 July 2008 09:56:55 UTC