W3C home > Mailing lists > Public > www-rdf-comments@w3.org > July to September 2002

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

From: Biron,Paul V <Paul.V.Biron@kp.org>
Date: Thu, 22 Aug 2002 16:15:04 -0700
Message-Id: <8904C60CACA7D51191BC00805FEAAF43D10AF1@crdc-exch-7.crdc.kp.org>
To: "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>, ht@cogsci.ed.ac.uk
Cc: Ashok Malhotra <ashokma@microsoft.com>, Dan Connolly <connolly@w3.org>, www-rdf-comments@w3.org, www-xml-schema-comments@w3.org

> -----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 name='myRestr'>
		<xs:restriction base='myUnion'>
			<xs:enumeration value='this is a test'/>
			<xs:enumeration value='10.0'/>
	<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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:18 UTC