The GML development team encountered this issue with Xerces. 
The process is that when the substitution group head is expanded into a =
<choice> group during validation, the cardinality constraint gets moved =
from the element declaration to the group container. 
Xerces does not happily move the cardinality constraints around even if =
they do produce "equivalent" content models. 

We came up with the following patterns to keep Xerces happy:

Change

   <complexType name="basicBitContainerType">
     <sequence>
       <element ref="test:basicBit" maxOccurs="unbounded"/>
     </sequence>
   </complexType>
   <complexType name="restrictedBasicBitContainerType">
     <complexContent>
       <restriction base="test:basicBitContainerType">
         <sequence>
           <element ref="test:restrictedBasicBit" =
maxOccurs="unbounded"/>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

to

   <complexType name="basicBitContainerType">
     <sequence>
       <element ref="test:basicBit" maxOccurs="unbounded"/>
     </sequence>
   </complexType>
   <complexType name="restrictedBasicBitContainerType">
     <complexContent>
       <restriction base="test:basicBitContainerType">
         <sequence>
		<choice maxOccurs="unbounded">
           	   <element ref="test:restrictedBasicBit"/>
		</choice>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

or more elegantly to

   <complexType name="basicBitContainerType">
     <sequence maxOccurs="unbounded">
       <element ref="test:basicBit"/>
     </sequence>
   </complexType>
   <complexType name="restrictedBasicBitContainerType">
     <complexContent>
       <restriction base="test:basicBitContainerType">
         <sequence maxOccurs="unbounded">
           <element ref="test:restrictedBasicBit"/>
         </sequence>
       </restriction>
     </complexContent>
   </complexType>

Simon Cox

> -----Original Message-----
> From: xmlschema-dev-request@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Michael Kay
> Sent: Thursday, 28 October 2004 7:17 AM
> To: 'Farber, Saul (ENV)'; xmlschema-dev@w...
> Subject: RE: I'd appreciate a second-look at this, just to 
> double-check
> 
> 
> Saxon reports this schema as valid, and as far as I can see, it is.
> 
> Rule 2.1 of Particle Valid (Restriction) in the PER [1] 
> explicitly caters for substitution groups:
> 
> Any top-level element declaration particle (in R or B) which 
> is the {substitution group affiliation} of one or more other 
> element declarations and whose =B7substitution group=B7 contains 
> at least one element declaration other than itself is treated 
> as if it were a choice group whose {min occurs} and {max 
> occurs} are those of the particle, and whose {particles} 
> consists of one particle with {min occurs} and {max occurs} 
> of 1 for each of the declarations in its =B7substitution group=B7.
> 
> You don't appear to have applied this step in your 
> walk-through of the algorithm.
> 
> Michael Kay
> 
> [1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#coss-particle
> 
>  
> 
> > -----Original Message-----
> > From: xmlschema-dev-request@w...
> > [mailto:xmlschema-dev-request@w...] On Behalf Of Farber, 
> Saul (ENV)
> > Sent: 27 October 2004 23:31
> > To: xmlschema-dev@w...
> > Subject: I'd appreciate a second-look at this, just to double-check
> > 
> > 
> > Hello experts!
> > 
> > First, let me say that I've been away from XML Schema for 
> over a year, 
> > and now that I'm back at it in a new context it's 
> immediately apparent 
> > how much the tools, community and support have improved in 
> the last 12 
> > to 18 months.  Good job and **THANKS** to everyone who's worked so 
> > hard for so long on this stuff.
> > 
> > Here's my question.  I'm getting an error when trying to 
> validate the 
> > following schema in Xerces 2.6.2.  First I'll show the schema:
> > 
> > <?xml version="1.0" encoding="UTF-8"?> <schema 
> > xmlns="http://www.w3.org/2001/XMLSchema"
> > targetNamespace="http://www.test.com/test" 
> > xmlns:test="http://www.test.com/test">
> >   <complexType name="basicBitType" abstract="true">
> >     <sequence>
> >       <element name="testElement" type="token" 
> maxOccurs="unbounded"/>
> >     </sequence>
> >   </complexType>
> >   <complexType name="restrictedBasicBitType">
> >     <complexContent>
> >       <restriction base="test:basicBitType">
> >         <sequence>
> >           <element name="testElement" type="token" =
maxOccurs="1"/>
> >         </sequence>
> >       </restriction>
> >     </complexContent>
> >   </complexType>
> >   <element name="basicBit" type="test:basicBitType" 
> abstract="true"/>
> >   <element name="restrictedBasicBit" 
> > type="test:restrictedBasicBitType" 
> substitutionGroup="test:basicBit"/>
> >   <complexType name="basicBitContainerType">
> >     <sequence>
> >       <element ref="test:basicBit" maxOccurs="unbounded"/>
> >     </sequence>
> >   </complexType>
> >   <complexType name="restrictedBasicBitContainerType">
> >     <complexContent>
> >       <restriction base="test:basicBitContainerType">
> >         <sequence>
> >           <element ref="test:restrictedBasicBit" 
> > maxOccurs="unbounded"/>
> >         </sequence>
> >       </restriction>
> >     </complexContent>
> >   </complexType>
> > </schema>
> > 
> > 
> > Now, the error comes up in the final complexType, 
> > "restrictedBasicBitContainer".  Xerces claims there is "not 
> a complete 
> > functional mapping between the particles" in the definition of the 
> > complexType "restrictedBasicBitContainerType".
> > 
> > I've looked through the spec, particularly the portion about 
> > restriction, and it looks like this SHOULD be valid.  Here're the 
> > relevant sentences that look like they stick to this bug:
> > 
> > 3.9.6 - Schema Particle Valid (Restriction) describes a set of 
> > rules...almost an algorithm for checking valid particle restriction.
> > 
> > Since we're restricting the base particle 
> "test:basicBitContainerType" 
> > that's where the algorithm will start.
> > 
> > Step 1) It's not pointless.  It's not an empty particle, 
> and it's not 
> > actually within ANY other particle.  So it's not pointless.
> > Step 2) We're restricting a sequence with another sequence, so 
> > according to the table, we "Recurse" on that sequence.
> > 
> > So we check:
> > 
> > *** "R's occurrence range is a valid restriction of B's occurrence 
> > range as defined by Occurrence Range OK (=A73.9.6)."
> > 
> > Check.  Both sequences have identical min and max occurs.
> > And we check:
> > 
> > ***"There is a complete =B7order-preserving=B7 functional 
> mapping from the 
> > particles in the {particles} of R to the ***particles in the 
> > {particles} of B such that all of the following must be true:"
> > 
> > ***"2.1 Each particle in the {particles} of R is a =B7valid 
> restriction=B7 
> > of the particle in the {particles} of B it maps ***to as defined by 
> > Particle Valid (Restriction) (=A73.9.6)."
> > 
> > Ok, I guess this is why they call it the "recurse" method.  
> > Our sub-particles are one single "element", so let's recurse into 
> > that.
> > 
> > ***"The declarations' {name}s and {target namespace}s are the same."
> > 
> > Uh, oh.  Our restricted particle name is in the same SUBSTITUTION 
> > GROUP as the particle it's restricting, but it doesn't have 
> the same 
> > name!  That's not so good.
> > 
> > 
> > 
> > So does this look like an accurate interpretation of the 
> > specification?  Am I looking at this the right way?  Should this be 
> > valid?
> > 
> > How good are most parsers at handling this?
> > 
> > 
> > Thanks again!
> > 
> > --saul
> > 
> > GIS Web Services
> > MassGIS - Executive Office of Environmental Affairs
> > 
> > 251 Causeway Street
> > 5th Floor
> > Boston, MA  02114
> > 617-626-1145
> > 
> > 
> > 
> 
> 
> 

From maksim@l... Thu Oct 28 17:58:00 2004
Received: from