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

I have a variation of Simon's case that common sense (imho) says should
be legal, but gets rejected and Simon's work-around does not really
apply.

Let there be a substitution group with head element H and members E1
and E2 (derived by extension from H's type).
Now I define two containers CType and RType, where RType is derived
from CType by restriction.
CType contains at least one H.
RType contains:
  one E1
  zero or one E2
  zero or more H
In my simple logic, RType forms a subset of all legal CTypes: it
contains at least one member of the substitution group H and may
contain more. The restriction is that it is required to contain one
element E1.  E2 is mainly there for decoration

   <complexType name="CType">
     <sequence>
       <element ref="H" maxOccurs="unbounded"/>
     </sequence>
   </complexType>
   <complexType name="RType">
     <complexContent>
       <restriction base="CType">
         <sequence>
           <element ref="E1"/>
           <element ref="E2" minOccurs="0" maxOccurs="unbounded"/>
           <element ref="H" minOccurs="0" maxOccurs="unbounded"/>
         </sequence>
       </restriction>
      </complexContent>
   </complexType>

To me, this would seem like an intended use of substitution groups in
derivation by restriction, but it gets caught up in a problem similar
to what was described in this thread - except that there does not seem
to be a similar work-around.

Am I wrong - on either count?

Cheers,

  _ Arnold Rots


-----Original Message-----
> From: Simon Cox
> Received on Thursday, 28 October 2004 11:12:52 GMT 
> 
> 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
> > > 
> > > 
> > > 
> > 
> > 
> > 
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

Received on Thursday, 20 January 2005 04:41:24 UTC