W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

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

From: Biron,Paul V <Paul.V.Biron@kp.org>
Date: Fri, 3 Nov 2000 12:13:06 -0800
Message-Id: <376E771642C1D2118DC300805FEAAF4386DFEB@pars-exch-1.ca.kp.org>
To: "Www-Xml-Schema-Comments@W3. Org" <www-xml-schema-comments@w3.org>
Cc: W3c-Xml-Schema-Ig <w3c-xml-schema-ig@w3.org>, Ningang chen <nchen@webmethods.com>
> -----Original Message-----
> From:	Asir S Vedamuthu [SMTP:asirv@webmethods.com]
> Sent:	Friday, November 03, 2000 7:50 AM
> To:	Www-Xml-Schema-Comments@W3. Org
> Cc:	W3c-Xml-Schema-Ig; Ningang chen
> Subject:	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
Like Henry, I'm having trouble seeing what the problem is.

> 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_det
> ai
> 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
Let's look at that constraint alittle closer...it says (in part):

	1.2.3. the {base type definition} is not the ur-type definition and
is validly
		derived from B given the subset as defined by this
constraint (if the
		{base type definition} is complex) or as defined in Type
		OK (Simple) (5.12) (if the {base type definition} is

The Type Derivation OK (Simple) constraint says (in part) [1]:

	A simple type definition (call it D, for derived) is validly derived
	from a simple type definition (call this B, for base) given a subset
	of {extension, restriction} (of which only restriction is actually
relevant) if: 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.

Thus, the rule is more complex than "Type definition compontent resolved
using the nominated value of xsi:type should be validly derived from the
declared type."  If you want, there is an "escape" clause for unions.

Therefore, the using xsi:type for things declared to be union types is NOT

> 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,
Which example in Part 2 are you referring to?

> <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
> 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.
As noted above, xsd:string does NOT have to be validly derived from the
union type, that is NOT what the relevant constraint in Part 1 requires.

> [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
> 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.
As I think Henry has pointed out, the above example is not syntactically
valid, the problem is that the pattern facet should be OUTSIDE the
union...actually its a little more complex than that, because you need to do
a restriction of the union in order to add the pattern facet...like this:

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

And again, xsd:string does NOT have to be derived from the union.

> 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
I don't understand what is being said here...

> Proposed solution
> Remove this xsi:type override from Union Type Definition. This will remove
> related inconsistencies.
No.  We need some way for instances to override the evaluation order (that
was very clear from the many comments we received on the union design).  The
"inconsistencies" you mention above are not real, and hence, there is no
reason to forbid the use of xsi:type when on unions.

> 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 does not say
> that Union Datatype Def can use pattern and enumeration facets.
My mistake, I thought that I had added that, I will do so right now.

> Section 4.1
> says that you can use two facets: pattern and enumeration.
Perhaps this confusion could be cleared up with some additional wording in
that constraint [2].  The table in the constraint lists the facets that can
be expected AT THE COMPONENT LEVEL on a simpleType definition.  That is,
when I'm looking at the component for a simpleType definition whose
"variety" is union, I should be prepared to see components for pattern and

As I think should be clear from 5.1.3 [3], you have to restrict a union type
in order to specify pattern and enumeration:

...when a datatype is derived from a union datatype, only the following
constraining facets can be used: 

> Production rule
> in section 5.1.3 does not allow pattern or enumeration as immediate
> children
> of xsd:union.
The above point solves this misconception as well.  That is, pattern and
enumeration are NOT allowed as children of xsd:union, but they ARE allowed
as children of xsd:restriction and you must restrict a union type to add

I'd not that this is exactly the way things work for list types as
well...when section and 5.1.2  [4,5] say:

When a datatype is derived from a list datatype, the following constraining
facets can be used: 

what they mean is that to specify a list of 4 integers you must do:

<xsd:simpleType name='list-of-4-ints'>
			<xsd:list itemType='xsd:integer'/>
		<xsd:length value='4'/>

In short, 1) there is no problem with using xsi:type on unions; 2) there is
no inconsistency in the prose as to which facets are applicable; 3) perhaps
some additional prose could be added to [2] to clarify its meaning.


[1] http://www.w3.org/TR/xmlschema-1.html#cos-st-derived-ok
[2] http://www.w3.org/TR/xmlschema-2.html#cos-applicable-facets
[3] http://www.w3.org/TR/xmlschema-2.html#derivation-by-union
[4] http://www.w3.org/TR/xmlschema-2.html#atomic-vs-list
[5] http://www.w3.org/TR/xmlschema-2.html#derivation-by-list
Received on Friday, 3 November 2000 15:38:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:49 UTC