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

> -----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
Derivation
		OK (Simple) (§5.12) (if the {base type definition} is
simple). 

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: 

	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.

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

> 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
> 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.
> 
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
> 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.
> 
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:simpleType>
		<xsd:restriction>
			<xsd:union memberTypes='xsd:integer xsd:string'/>
			<xsd:pattern value='1'/>
			<xsd:pattern value='1|2'/>
			<xsd:pattern value='small|medium|large'/>
		</xsd:restriction>
	</xsd:simpleType>
</xsd:element>

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
> TRUE.
> 
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 2.5.1.3 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
enumeration.

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: 
              pattern 
              enumeration

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

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

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

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

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

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.

pvb

References
[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