Problems with <sequence> pointlessness

In my schema:

   <complexType name="base">
     <complexContent>
       <sequence>
         <element ref="ns:a" minOccurs="0" maxOccurs="1"/>
	  <choice minOccurs="0" maxOccurs="unbounded">
           <element ref="ns:b"/>
           <element ref="ns:c"/>
         </choice>
       </sequence>
     </complexContent>
   </complexType>

...

   <complexType name="derived">
     <complexContent>
       <restriction base="ns:base">
         <sequence>
	    <choice minOccurs="0" maxOccurs="unbounded">
             <element ref="ns:b"/>
             <element ref="ns:c"/>
           </choice>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

I.e. my intention is that derived does not allow an <a> child but is
otherwise identical to base.

According to one interpretation of rules in
http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict, the <sequence> in
the definition of derived is pointless since 2.2.2.2.1 applies, "The
<sequence>'s {particles} has only one member." and is therefore ignored. As
a result its <choice> child is checked against the <sequence> in the
definition of base. This Choice:Sequence restriction is forbidden according
to the table.

<waves-hands>
   How is pointlessness supposed to be applied? It seems to me that
pointlessness must be determined in the derived type with reference to the
base type (and vice-versa?) i.e. that actually the <sequence> in my derived
type is not pointless!
</waves-hands>


Many thanks for any help,
Gareth


(This question is brought to you by the differences between Xerces-C++ and
Xerces-Java...)


*************************************************************************
The information contained in this message or any of its
attachments may be privileged and confidential and intended
for the exclusive use of the addressee. If you are not the
addressee any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited
*************************************************************************

Received on Thursday, 14 August 2003 08:51:06 UTC