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

Hi,

I remember I also run into a similar problem some time ago...
I was about to report a bug against Xerces but then I tried to apply the 
algorithm by hand and it seems that Xerces is right, see below.

Applying rule 2.1 on:

B:
      <sequence>
          <element ref="test:basicBit" maxOccurs="unbounded"/>
      </sequence>
  R:
     <sequence>
         <element ref="test:restrictedBasicBit" maxOccurs="unbounded"/>
     </sequence>

will give:

B:

     <choice minOccurs="1" maxOccurs="unbounded">
       <element ref="test:basicBit" minOccurs="1" maxOccurs="1"/>
       <element ref="test:restrictedBasicBit" minOccurs="1" maxOccurs="1"/>
     <choice>

R:

     <element ref="test:restrictedBasicBit" maxOccurs="unbounded"/>


We apply then http://www.w3.org/TR/xmlschema-1/#rcase-RecurseAsIfGroup

B:
   <choice minOccurs="1" maxOccurs="unbounded">
       <element ref="test:basicBit" minOccurs="1" maxOccurs="1"/>
       <element ref="test:restrictedBasicBit" minOccurs="1" maxOccurs="1"/>
     <choice>

R:
     <choice minOccurs="1" maxOccurs="1">
         <element ref="test:restrictedBasicBit" maxOccurs="unbounded"/>
     </choice>

and following http://www.w3.org/TR/xmlschema-1/#rcase-RecurseLax we need 
to map

       <element ref="test:basicBit" minOccurs="1" maxOccurs="1"/>
       <element ref="test:restrictedBasicBit" minOccurs="1"

to

       <element ref="test:restrictedBasicBit" maxOccurs="unbounded"/>


which cannot be done.

Please let me know if I missed somethig.

A simple workaround is to write the restrictedBasicBitContainerType as 
below:

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

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Michael Kay wrote:
> 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 07:33:03 UTC