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

> -----Original Message-----
> From:	noah_mendelsohn@us.ibm.com [SMTP:noah_mendelsohn@us.ibm.com]
> Sent:	Thursday, August 22, 2002 12:21 PM
> To:	ht@cogsci.ed.ac.uk
> Cc:	Ashok Malhotra; Dan Connolly; www-rdf-comments@w3.org; www-xml-schema-comments@w3.org
> Subject:	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. 
> 
Yes, of course we allow that.  Why is this funny...order in the definition matters unless you specifically override that order with xsi:type...

> 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.
> 
We don't allow any facets to be specified directly on the union (i.e., when the union itself is defined).  But, when a type is derived from a union type, we only allow pattern and enumeration to be specified...regardless of the facets that are applicable to the member types.

Thus, the following is allowed:

	<xs:simpleType name='myUnion'>
		<xs:union memberTypes='xs:string xs:decimal'/>
	</xs:simpleType>
	<xs:simpleType name='myRestr'>
		<xs:restriction base='myUnion'>
			<xs:enumeration value='this is a test'/>
			<xs:enumeration value='10.0'/>
		</xs:restriction>
	</xs:simpleType>
	<xs:element name='foo' type='myRestr'/>

But, yes you probably are right that there's a whole in that you can't give an xsi:type on the enumeration value...so that the 2nd enumerated value is correctly interpreted as a decimal rather than a string.  We should do a fix or 1.1 or 2.0.

I think there also may be something askew in that if you have

	<foo xsi:type='xs:decimal'>20.0</foo>

chances are we didn't get the rules right in structures to check that if foo is declared of a union type then the xsi:type discriminator should be used to examine just that portion of the union's value space and not check it against the xsi:type directly.

pvb

Received on Thursday, 22 August 2002 20:12:05 UTC