Re: Implementation Experience: INCORRECT usage of xsi:type in Union Types

"Asir S Vedamuthu" <asirv@webmethods.com> writes:

I'm finding the argument hard to follow, so will concentrate on the examples.

> [Example 1] This is a modified example ('cos the original example is
> incorrect, both syntactically and semantically) from Part 2,

Please give us a reference to the original broken example.

> <xsd:element name='size'>
>   <xsd:simpleType>
>     <xsd:union>
>     <xsd:simpleType>
>       <xsd:restriction base='xsd:integer'/>
>     </xsd:simpleType>
>     <xsd:simpleType>
>       <xsd:restriction base='xsd:string'>
> 	  <xsd:enumeration value='5'/>
> 	  <xsd:enumeration value='6'/>
> 	</xsd:restriction>
>     </xsd:simpleType>
>   </xsd:union>
>  </xsd:simpleType>
> </xsd:element>
> 
> <size xsi:type='xsd:string'>1</size>
> 
> In the above example, 'xsd:string' one of the primitive built-in type is NOT
> VALIDLY DERIVED from the defined union type. Defined union type contains two
> anonymous types. Instance can never NEVER identify one of the members using
> a QName.

Correct.  What is the implementation problem -- note an error and move 
on.

> <xsd:element name='size'>
>   <xsd:simpleType>
>     <xsd:union memberTypes='xsd:integer xsd:string'>
> 	<xsd:pattern value='1'/>
> 	<xsd:pattern value='(1|2)'/>
> 	<xsd:pattern value='(small|medium|large)'/>
>     </xsd:union>
>   </xsd:simpleType>
> </xsd:element>
> 
> <size xsi:type='xsd:string'>small</size>
> 
> In the above example, 'xsd:string' one of the primitive built-in type is NOT
> VALIDLY DERIVED from the defined union type. Defined union type contains two
> named built-in types. However the lexical space of the newly defined type is
> constrained by the patterns.

I'm not sure what you're getting at here.  Stipulate that the
declaration above is corrected syntactically to

<xsd:element name='size'>
 <xsd:simpleType>
  <xsd:restriction>
   <xsd:simpleType>
     <xsd:union memberTypes='xsd:integer xsd:string'/>
   </xsd:simpleType>
   <xsd:pattern value='1'/>
   <xsd:pattern value='(1|2)'/>
   <xsd:pattern value='(small|medium|large)'/>
  </xsd:restriction>
 </xsd:simpleType>
</xsd:element>

<size xsi:type='xsd:string'>small</size>

Two things:

 1) Your type is empty, I think -- that is, because multiple patterns
    are conjoined, you require something impossible to satisfy.

 2) Leaving that aside, according to the CR draft, the instance is
 valid: 'small' is certainly a string, and 'xsd:string' can appear
 because clause 1.2.2.4 of [1] says xsd:string (D) is validly derived
 from union(xsd:string, xsd:integer) (B) if:

     "1.2.2.4 B's {variety} is union and D is validly derived from a
     type definition in B's {member type definitions} given the
     subset, as defined by this constraint.

  So the CR draft says this instance is OK.  I'm not sure whether this 
is a catastrophe or not, but if we think it is, the fix is obvious:
amend 1.2.2.4 to either
   a) require that the union (B) have no constraining facets of its own;
   b) require that the candidate (D) have facets at least as
      constraining as the union (B)
I'm not sure which I'd prefer.

> Proposed solution
> 
> Remove this xsi:type override from Union Type Definition. This will remove
> related inconsistencies.

That would work too -- it would mean removing 1.2.2.4 as well.  I
would rather not do this.

ht

[1] http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#cos-st-derived-ok
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Friday, 3 November 2000 13:37:09 UTC