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 Wednesday, 27 October 2004 23:16:57 UTC