Re: QName is ambiguous; aren't datatypes unambiguous? union types total?

Henry Thompson corrects me regarding the interpretation of a union of two 
types with overlapping lexical spaces (e.g. string & decimal):

>> That can't be right, since the following is allowed, given a
>> definition of my:u as union(xs:string,xs:decimal) and foo declared to
>> have my:u as its type:

>>      <foo xsi:type="xs:decimal">10</foo>

Ugh, we allow that?  I'm surprised and disappointed.  Oh well....  If we 
do, then clearly the value space of a union is truly the union of the 
value spaces.  Something feels funny to me about this state of affairs 
(I.e. order matters in the absence of xsi:type, but not when xsi:type is 
present), but I can't quite pin it down. 

Question: do we allow facets like enumeration on the union, as opposed to 
on the constituent types?  If so, are they enforced in the presence of an 
xsi:type such as above?  Can't prove it's broken, but the combination 
seems very strange.  The straight lexical forms in the absence of xsi:type 
are those that are visible per the type ordering, and the values assigned 
to any enumeration would be accordingly.  Thus, you could not enumerate 
the decimal "10" in an enumeration facet on the union.  Nonetheless, you 
could supply the value 10 in an instance as shown above.  Seems very 
asymmetric to have values in a type that you can't enumerate.  Almost 
surely not worth changing now, but I might have argued for thinking this 
through more carefully if I'd noticed it during the original design work.

Anyway, thanks for the clarification, and sorry for any confusion caused.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 22 August 2002 15:22:50 UTC