Re: derivation by restriction and to - definition 2

[Lucian Holland]

Usorov, Evgeny wrote:
<xs:complexType name="basis_typ">
        <xs:sequence>
                <xs:element name="added_element"/>
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                        <xs:element name="foo" minOccurs="0" maxOccurs="unbounded"/>
                        <xs:element name="bar" minOccurs="0" maxOccurs="unbounded"/>
                </xs:choice>
        </xs:sequence>            
</xs:complexType> 
to
        <xs:complexType name="derived_test_typ">
                <xs:complexContent>
                        <xs:restriction base="basis_typ">
                                        <xs:sequence>
                                                <xs:element name="added_element"/>
                                                <xs:element name="foo" minOccurs="2" 
maxOccurs="2"/>
                                                <xs:element name="bar" minOccurs="4" 
maxOccurs="4"/>
                                        </xs:sequence>
                        </xs:restriction>
                </xs:complexContent>
        </xs:complexType>
i think this is a bug.
 

You're right - this is a bug. Unfortunately it is a bug in the schema 
spec rather than Xerces. The reason that Xerces objects to your 
restriction is that there isn't a one-to-one mapping between the 
particles of the derived sequence and the particles of the base. If you 
look, the outer sequence in the base has two particles: "added_element" 
and the choice; but the derived sequence has three - "added_element", 
"foo" and "bar".  You and I can both see that anything valid for the 
restriction will be valid for the base, but unfortunately the algorithm 
defined in the schema spec for determining what constitutes a valid 
restriction is far from perfect. The obvious way round this would be to do:

<xs:complexType name="derived_test_typ">
        <xs:complexContent>
                <xs:restriction base="basis_typ">
                        <xs:sequence>
                                <xs:element name="added_element"/>
                                <xs:sequence>
                                        <xs:element name="foo" minOccurs="2" 
maxOccurs="2"/>
                                        <xs:element name="bar" minOccurs="4" 
maxOccurs="4"/>
                                </xs:sequence>
                        </xs:sequence>
                </xs:restriction>
        </xs:complexContent>
</xs:complexType>
Unfortunately the schema spec has that one covered as well :-) There's a 
cunning little clause in there about pointless particles, the net result 
of which is that the inner sequence will be merged into the outer one 
prior to processing, on the grounds that its pointless. It *is* 
pointless from a formal point of view, but unfortunately it is very 
necessary for making it clear to the algorithm which particles in the 
derived type are intended to be restrictions of which particles in the 
base; so the spec gets you coming and going - gotta love it :-)

If you're feeling strong the relevant section of the schema spec can be 
found at:

http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#cos-particle-restrict
If it's any consolation I believe that this is on the todo list for Schema 1.1...
Lucian
--
Lucian Holland, Technical Architect    +44-1865-203192
DecisionSoft Limited                   http://www.decisionsoft.com
XML Development and Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]