- From: Don Box <dbox@microsoft.com>
- Date: Thu, 5 Dec 2002 01:16:35 -0800
- To: <www-xml-schema-comments@w3.org>
- Cc: "Ashok Malhotra" <ashokma@microsoft.com>, "Martin Gudgin" <mgudgin@microsoft.com>, "Allen Brown" <allenbr@microsoft.com>
- Message-ID: <CFC4F26947496E4092489B2425614958057FA935@svc-msg-02.northamerica.corp.microsoft>
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
Received on Thursday, 5 December 2002 04:17:16 UTC