Re: [xsl] Type of a variable containing values of mixed types

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

For reasons which I do not claim to fully understand, the XPath/XSD type
system for atomic types is based on the notion of explicit type labels, rather
than being purely predicate-based. For example, the number 3 may or may not be
an instance of xs:positiveInteger; the fact that it satisfies all the rules
for xs:positiveInteger does not mean that it is one. It is only an
xs:positiveInteger if it is labelled as such, for example by being the value
of an attribute with a declared type of xs:positiveInteger. This means that a
type is not simply a value space. By contrast, union types (at any rate "pure"
unions) come much closer to being predicate-based: if M is a member type of U,
then every instance of M is an instance of U by definition.

This also means that a base type B with (X, Y, Z) as its (only) subtypes is
not quite the same as a (pure) union type U with (X, Y, Z) as its derived
types. In many respects they behave the same way: for example (V instance of
B) and (V instance of U) give the same result, and declaring a function
argument with the required type B or U has the same effect. One difference is
that there is the cast operation (P cast as U) will always return either an
instance of X, Y, or Z, or an error; whereas (P cast as B) will typically
return an instance of B that is not an instance of X, Y, or Z. Probably the
main difference of principle is that with a base type B, you have to assume
that the set of possible derived types is infinite and unknown, whereas with a
union type you can assume that the member types are known and enumerable.

Having said all that, I think the reasons for making xs:numeric a union type
rather than a base type for xs:double, xs:decimal, and xs:float were
pragmatic: either approach would have worked technically. Making it a base
type would have involved either changes to XSD, or a divergence between the
XSD and XDM type hierarchies, both of which would have had messy consequences.
Introducing a union type, having done all the groundwork to provide proper
support for union types in general, was much more straightforward.

Michael Kay
Saxonica
mike@xxxxxxxxxxxx
+44 (0) 118 946 5893




On 14 Apr 2015, at 14:25, Justin Johansson procode@xxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> This question has been on my TODO list to ask the folks at MulberryTech XSL
List for quite some time.
>
> I think this came about in XPath DM 3.0 regarding xs:numeric as per spec
ref:
>
> http://www.w3.org/TR/xpath-datamodel-3/#types-hierarchy
>
> In the type hierachy xs:numeric now appears for the first time spec-wise (I
believe) and it's on the right-hand side under "union types".
>
> Mathematically this seems inconsistent with respect to xs:anyAtomicType
given that it as a diagrammed type itself appears on the left-hand side of the
type hierarchy diagram and so does not identify itself as a union type. But
surely xs:anyAtomicType is in fact a union type
(set-theoretically/type-theoretically speaking). So with respect to
"union/non-union" reasoning which is correct xs:anyAtomicType or xs:numeric as
far as the diagram goes? Or, rephasing, why is xs:numeric treated somehow
differently to xs:anyAtomicType?
>
> On the other hand, perhaps this is all to do with some practical reason for
injecting xs:numeric into the XPath DM 3.0 type hierarchy as a union type so
as not to disaffect the status quo?
>
> Any thoughts/insight from XSL List community?
>
> Justin Johansson
>
> Twitter: b@MartianOdyssey : Project Clockwork: My invention of the fastest
and most extensible XPath engine for the JVM (or so I aspire to).
>
> XSL-List info and archive
> EasyUnsubscribe (by email)