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

Thanks, this is very helpful.  The latter part of your note reinforces my 
concern that we have architecuturally complicated things by introducing 
types (I.e. unions) in which there are lexical forms that can be 
"activated"  only through use of xsi:type.  I'm a bit nervous that the 
edge cases we've been discussing aren't the last ones we'll discover. 
Still, if we've gone this route, I think we've no choice at this point but 
to deal with any anomolies, as you suggest.   Thanks again.

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







"Biron,Paul V" <Paul.V.Biron@kp.org>
08/22/2002 07:15 PM

 
        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
        Subject:        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 Friday, 23 August 2002 10:11:22 UTC