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

["Justin Johansson procode@xxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Wow, thank you very much Michael Kay for your thorough and well-thought 
response.

Rumour has it, given your ability to speak-think-and-type, that you must 
be a machine!

Regards, Justin Johansson


On 14/04/15 23:35, Michael Kay mike@xxxxxxxxxxxx wrote:
> 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 ...

> 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 <mailto:mike@xxxxxxxxxxxx>
> +44 (0) 118 946 5893
>
>
>
>
> On 14 Apr 2015, at 14:25, Justin Johansson procode@xxxxxxxxxxx 
> <mailto:procode@xxxxxxxxxxx> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx 
> <mailto: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* <https://twitter.com/MartianOdyssey> : 
>> Project Clockwork: My invention of the fastest and most extensible 
>> XPath engine for the JVM (superlatives aspirational).