Re: Handling the enumeration facet

> The example is not valid.  The enumeration needs to be done in a separate 
> step, as follows:

You are right. I forgot to include the union in a separate anonymous simple 
type definition. But I think my previous question remains valid even if we 
use the simple types s1 and s2.

>From my point of view the main question is whether the default evaluation 
order only applies when validating instance documents or whether it also 
applies for the enumeration facet. I think xsi:type is a hint that it is 
only a _default_ evaluation order.

When parsing instance documents it is important that the parsed literal gets 
a specific type (like xs:integer or xs:string) but when parsing the 
enumeration value of unions it isn't necessary to pin it down to a specific 
type because unions are allowed to contain different values for the same 
literal. Only when parsing the instance document it must be clear which type 
the value has and there applies the default evaluation order or the order 
defined by xsi:type.


> FWIW Xerces reports this as valid, it allows both the integer and the 
> string value.

You are right. Xerces reports this as valid but that's not an argument ;-) 
Also Xerces can be wrong. My problem is that I understand both positions. 
I'm currently collecting opinions which position is more reasonable because 
the spec is, from my point of view, unclear in this point.


> The value space is a set of values and I do not find a distinction between 
> string 10 and integer 10 in the value space. Let me know if I'm missing 
> something.

I think the value space makes this distinction. If you think in the way of 
higher programming languages then this distinction is definitely made. And 
it is also not contradictionary that all values in the value space are 
defined as xs:anySimpleType because all types are derived from it. So all 
values such as xs:integer and xs:string would also be xs:anySimpleType.


Cheers
Klaas

Received on Friday, 31 December 2004 11:55:39 UTC