Re: Rationale for restricted uses of "all"

Mark,
The schema specification states that extension is always required to
*append* derived content to the base type, with a brief statement that
this makes it easier to test conformance of any specializations
against the base type definition.

If you interpret this such that the derived type is validated as the
<all> group from the base type, followed by the <all> group from the
derived type, then your example should be valid.  Indeed, if I test
your example against the latest 1.3 version of XSV, it validates
successfully.  However, if I modify your instance document such that
Child2 precedes Child1, then I get a validation error.

To expand this test, I added to your sample as follows, so the base
type has two elements, Child1 and Child2, and the extended class adds
Child3.  I can then successfully validate an instance where the first
two elements are unordered (2 before 1) followed by Child3.

If XSV is the correct interpretation, then the error you received is a
bug in Xerces.

xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
     <xs:complexType name="A">
          <xs:all>
               <xs:element name="Child1"/>
               <xs:element name="Child2"/>
          </xs:all>
     </xs:complexType>
     <xs:complexType name="B">
          <xs:complexContent>
               <xs:extension base="A">
                    <xs:all>
                         <xs:element name="Child3"/>
                    </xs:all>
               </xs:extension>
          </xs:complexContent>
     </xs:complexType>
     <xs:element name="ElementA" type="B"/>
</xs:schema>

This instance validates successfully in XSV 1.3, so the first 2
elements are unordered, followed by the 3rd:

<ElementA xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="allAgain.xsd">
   <Child2/>
   <Child1/>
   <Child3/>
</ElementA>


----- Original Message -----
From: "Mark Feblowitz" <mfeblowitz@frictionless.com>
To: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>
Sent: Thursday, November 08, 2001 11:00 AM
Subject: Rationale for restricted uses of "all"


>
> Just curious: what are the rationale for the particular constraints
on the
> use of "all"? Is it that parsing becomes intractable, or are there
other
> issues?
>
> Schema Component Constraint: All Group Limited
> When a model group has {compositor} all all of the following
> must be true:
> 1 one of the following must be true:
> 1.1 It appears as the model group of a model group
> definition.
> 1.2 It appears in a particle with {min occurs}={max
> occurs}=1, and that particle must be part of a pair which
constitutes the
> {content type} of a complex type definition.
> 2 The {max occurs} of all the particles in the {particles}
> of the group must be 0 or 1.
>
>
> Also, the constraints also restrict the ability to combine all
groups
> through "inheritance?" Say a base type has an all group and an
extension of
> that type also defines an all group:
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>      <xs:complexType name="A">
>           <xs:all>
>                <xs:element name="Child1"/>
>           </xs:all>
>      </xs:complexType>
>      <xs:complexType name="B">
>           <xs:complexContent>
>                <xs:extension base="A">
>                     <xs:all>
>                          <xs:element name="Child2"/>
>                     </xs:all>
>                </xs:extension>
>           </xs:complexContent>
>      </xs:complexType>
>      <xs:element name="ElementA" type="B"/>
> </xs:schema>
>
> Could they be interpreted as a single, combined all group?
>
> <ElementA xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:noNamespaceSchemaLocation="allAgain.xsd">
>    <Child1/>
>    <Child2/>
> </ElementA>
>
> At present, Xerces reports
>
> [Error] allAgain.xml:3:138: schema error:
> cos-all-limited.1.2:  An "all" model group that is part of a complex
type
> definition must constitute the entire {content type} of the
definition.
>
> XML Spy And XSV report no errors.
>
>
>
>
>
> --------------------------------------------------------------------
--------
> ----
>
> Mark Feblowitz                                   [t] 617.715.7231
> Frictionless Commerce Incorporated     [f] 617.495.0188
> XML Architect                                     [e]
> mfeblowitz@frictionless.com
> 400 Technology Square, 9th Floor
> Cambridge, MA 02139
> www.frictionless.com
>
>
>
>

Received on Thursday, 8 November 2001 21:32:18 UTC