I just realized that you cannot combine derivation by restriction with
namespace qualified local elements (or attributes) when the derived type
is in a different namespace than its base type.
Consider this base type:
<xs:schema targetNamespace="urn:a:aaa"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:a="urn:a:aaa"
>
<xs:complexType name="Base" >
<xs:sequence>
<xs:element name="x" type="xs:int" form="qualified" />
<xs:element name="y" type="xs:int" minOccurs="0" form="qualified"
/>
</xs:sequence>
</xs:complexType>
<xs:element name="BE" type="a:Base" />
</xs:schema>
There is no way to derive from this type by restriction in any namespace
other than urn:a:aaa. Consider this attempt:
<xs:schema targetNamespace="urn:b:bbb"
xmlns:a="urn:a:aaa"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
<xs:complexType name="Derived">
<xs:complexContent>
<xs:restriction base="Base" >
<xs:sequence>
<xs:element name="x" type="xs:int" form="qualified" />
<xs:element name="y" type="xs:int" minOccurs="1"
form="qualified" />
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
both XSV and System.Xml (correctly) reject this schema. This is because
an instance would look like this:
<a:BE xsi:type="b:Derived" >
<b:x>3</b:x>
<b:y>3</b:y>
</a:BE>
which of course is not a legal instance of a:Base because of the
namespace affiliation of x and y.
The problem does not occur if the particles in Base are references to
GEDs or Unqualified local elements. The presence of qualified local
elements effectively renders the a:Base final="restriction" for types
that are in other namespaces.
As far as I can tell, the post-1.0 proposals to change the mechanism for
how derivation by restriction is expressed (e.g., by subtyping) won't
help.
One simple solution to this problem would be to change the way namespace
affiliation for qualified local members is calculated in a post-1.0
version of schema.
For example, given the following type hierarchy (in pseudo-schema):
complexType A {}
complexType B restricts A {}
complexType C restricts B {}
complexType D restricts C {}
complexType E extends D {}
complexType F restricts E {}
complexType G restricts F {}
If namespace affiliation for qualified local members was based on either
(a) the most-general base type or (b) the most-general base type
accessible only through derivations by restriction, then I believe the
problem would be solved. Under approach (a), the namespace affiliation
for local members of types A-G would be the namespace of A. Under
approach (b), the affiliations would be:
A: namespace(a)
B: namespace(a)
C: namespace(a)
D: namespace(a)
E: namespace(e)
F: namespace(e)
G: namespace(e)
This is consistent with the "instance-of" assumptions of both derivation
by restriction and extension.
Of the two, I prefer (b) as it would not break any existing legal
schemas. At worst, (b) would only affect schemas that were relying on
this obscure incompatibility to block cross-namespace derivation, as now
one could actually do it.
DB