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 Wednesday, 27 October 2004 22:32:30 UTC