- From: <Joe.Misner@ivans.com>
- Date: Wed, 11 Sep 2002 18:36:59 -0400 (EDT)
- To: xmlschema-dev@w3.org
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 UTC