RE: I'd appreciate a second-look at this, just to double-check

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@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael Kay
> Sent: Thursday, 28 October 2004 7:17 AM
> To: 'Farber, Saul (ENV)'; xmlschema-dev@w3.org
> 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 ·substitution group· 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 ·substitution group·.
> 
> 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@w3.org
> > [mailto:xmlschema-dev-request@w3.org] On Behalf Of Farber, 
> Saul (ENV)
> > Sent: 27 October 2004 23:31
> > To: xmlschema-dev@w3.org
> > 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 (§3.9.6)."
> > 
> > Check.  Both sequences have identical min and max occurs.
> > And we check:
> > 
> > ***"There is a complete ·order-preserving· 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 ·valid 
> restriction· 
> > of the particle in the {particles} of B it maps ***to as defined by 
> > Particle Valid (Restriction) (§3.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
> > 
> > 
> > 
> 
> 
>

Received on Thursday, 28 October 2004 11:12:52 UTC