W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2002

How Do I Force Instances To Use Specific Derived Types?

From: <Joe.Misner@ivans.com>
Date: Wed, 11 Sep 2002 18:36:59 -0400 (EDT)
To: xmlschema-dev@w3.org
Message-Id: <"0911223220-How Do I Force Instances To Use Specific Derived Type*/G=Joe/S=Misner/O=ivans/PRMD=notes/ADMD=mailconnect/C=us/"@MHS>





I am trying to figure out how a schema can be written that will force valid 
instance documents to use a SPECIFIC derived type (not just any derived type) 
instead of the base type wherever the base type is expected.  This becomes a 
real-world issue when one organization imports another organization's 
namespace, restricts one of its types, and then wishes to force its users to 
use its derived type rather than the other organization's base type (but still 
wants users to use the element name originally prescribed rather than a new 
element name).

Let me offer a specific, entirely hypothetical scenario.

Suppose OrgA is a standards-issuer for some vertical market.  Suppose it 
publishes a schema that looks like this:

<xsd:schema targetNamespace="www.OrgA.org/BigSchema" ...>
<xsd:complexType name="TypeA">
	<!-- Specific content not relevant.  -->
</xsd:complexType>
<xsd:element name="ElementOfTypeA" type="TypeA" />

Now suppose CompanyB is a user of OrgA's standards.  It cannot process every 
element that satisfies the definition of TypeA, but it is prepared to process a 
subset of those elements.  So it publishes a schema that looks like this:

<xsd:schema targetNamespace="www.CompanyB.com/LittleSchema" 
xmlns:OrgA="www.OrgA.org/BigSchema" ...>
<xsd:import namespace="www.OrgA.org/Bigschema" .../>
<xsd:complexType name="LimitedTypeA">
	<xsd:complexContent>
		<xsd:restriction base="OrgA:TypeA">
			<!-- Specific restrictions not relevant. -->
		</xsd:restriction>
	</xsd:complexContent>
</xsd:complexType>

CompanyB wants to receive instances that look more or less like this:

<Root xmlns="www.OrgA.org/BigSchema" xmlns:B="www.CompanyB.com/LittleSchema">
	...
	<ElementOfTypeA xsi:type="B:LimitedTypeA">
		<!-- Content conforming to B's restrictions.  -->
	</ElementOfTypeA>
</Root>

This is all perfectly legal.  But the problem (as I see it) is that CompanyB is 
basically placing its trading partners on the honor system to actually do this. 
 If, instead, a trading partner were to send the following document to 
CompanyB:

<Root xmlns="www.OrgA.org/BigSchema">
	...
	<ElementOfTypeA>
		<!-- Content NOT conforming to B's restrictions, but valid against the base 
TypeA type.  -->
	</ElementOfTypeA>
</Root>

the schema validator would deem it entirely valid, which it is.  But CompanyB 
would not be able to process it.

I thought about making TypeA an abstract type, which would force instances to 
use xsi:type.  But there are two problems: (1) CompanyB can't make OrgA change 
its schema to do this; and (2) even if this were done, it wouldn't force B's 
trading partners to use "B:LimitedTypeA" in their instance documents - they 
could use ANY type derived from TypeA and still pass schema validation.

It seems like there ought to be a way for CompanyB's schema to limit the values 
of xsi:type.  If CompanyB could do that, then it could limit xsi:type to a 
fixed value for the ElementOfTypeA element, or to an enumerated list of types 
(all derived from OrgA:TypeA ) that CompanyB is prepared to receive.  But 
Section 3.2.6 of Schema Part 1 seems to say rather emphatically that none of 
the xsi: attributes may be restricted.

Another idea is for CompanyB to define a required element in its schema which 
is specifically typed the way CompanyB needs to receive it, as follows:

(CompanyB schema targeting its own namespace):

<xsd:element name="BElementOfTypeA" type="LimitedTypeA" />
<xsd:element name="Root">
	<xsd:complexContent>
		<xsd:extension base="OrgA:Root>
			<xsd:sequence>
				<xsd:element ref="BElementOfTypeA" minOccurs="1" />
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:element>

But this makes the instance documents get really messy, because they must now 
use this new tag <B:BElementOfTypeA> rather than <ElementOfTypeA>.  It must be 
at the end of <Root>'s content model rather than in its normal place, because 
it is a new element added to it.  Worst of all, it doesn't solve the problem, 
because the trading partner is still on his honor to put an xsi:type="B:Root" 
on his <Root> element in order to incorporate this extra tag.

Is there a solution that doesn't require CompanyB to put its trading partners 
on the honor system?


Joe Misner
Software Architect
IVANS Inc.
Email: Joe.Misner@ivans.com
Phone:  513-943-8716
Fax: 203-601-4228
Received on Thursday, 12 September 2002 04:34:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:34 GMT