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 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 19 July 2008 09:56:57 GMT