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

Evaluation order specified in a Union Type Definition is significant. During
validation, processor evaluates element or attribute's content in the order
specified in the definition. CR drafts also say that an XML instance can
nominate one of the union member types and intercept the evaluation order.
Reference -
http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#dt-union

Usage of xsi:type in Union Types, as defined in the CR drafts, is incorrect
'COS,

[1] As per Part 1, in section 3.3, element declaration details,

Reference -
http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#Element_Declaration_detai
ls

Type definition component resolved using the nominated value of xsi:type
should be validly derived from the declared type. In this specific case,
xsi:type is used to identify one of the union member types. 90% of the
cases, a member of the union type can NEVER be VALIDLY DERIVED from the
declared union type (why? read below) 'cos of the TYPE DERIVATION OK, one of
the many semantic constraints described in Part 1. Reference -
http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/#cos-ct-derived-ok


I will illustrate this scenario using two examples (on request, I can send
you more examples).


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

<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.


[Example 2]

<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.

One can argue that a member of the defined union type is a valid restriction
of the defined union type. From the above statement, this STATEMENT is NOT
TRUE.


Proposed solution

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



NOTE - there are several frustrating errors in prose that keeps me circling
thru the drafts. Asir, this is NORMAL 'cos of the last minute additions and
substrations. Of them, here is one. Part 2 - Section 2.5.1.3 does not say
that Union Datatype Def can use pattern and enumeration facets. Section 4.1
says that you can use two facets: pattern and enumeration. Production rule
in section 5.1.3 does not allow pattern or enumeration as immediate children
of xsd:union.


All the best,

Asir S Vedamuthu
webMethods, Inc.
(Phone) 703-460-2513 (Fax) 703-460-2513 (E-mail) asirv@webmethods.com
URL: http://www.webmethods.com

Received on Friday, 3 November 2000 10:50:00 UTC