STC and Xerces

[Arnold Rots]

Ray,

Thank you for your detective work.
Actually, I had (or thought I had) validated the schemata against
Xerces, using the DecisionSoft web service - except, I hadn't fed it a
document but used their schema-only validation service.
Validating with a document yields the same errors you find; btw, I put
the five examples on my webpage.

I tried something along the lines of the GML work-around, but I don't
think it will work (and I didn't manage to get it to work).
The reason is that I take the next step and assume that the rule
allows one to do math and that the validator is capable of doing so:

Simon Cox shows the work-around for:

   <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>

The equivalent of what I am trying to do is:

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

I.e., basicBitContainerType is required to contain at least 1 basicBit;
restrictedBasicBitContainerType contains 1 restrictedBasicBit (in
basicBit's substitution group) and may contain more basicBits.
So, the restriction really is that the one required basicBit be a
restrictedBasicBit.

Sigh...

  - Arnold

Ray Plante wrote:
> Hi Arnold,
> 
> I've been looking into the errors reported by Xerces on STC that feature
> the message, "The particle of the type is not a valid restriction of the
> particle of the base", and I have good news and bad news.  The pattern at
> issue is one of restricting an element by replacing a subelement with a 
> specific member of the subelement's substitution group.
> 
> The bad news is that the pattern as you have applied it is indeed not
> allowed by the standard (which Xerces faithfully enforces), even
> though it was intended to be legal.  Combing through list archives,
> this was apparently recently discovered (by Simon Cox of CSIRO, as
> best as I can tell) and is considered by those In The Know as an error
> in the XML Schema standard.  As one writer put it, "it's one of those
> cases where [a parser] implementor has to choose between doing what
> the spec says and doing what it means"
> (http://lists.w3.org/Archives/Public/xmlschema-dev/2004Oct/0100.html).
> Restriction via a substitution group replacement is only allowed when 
> minOccurs and maxOccurs on the subelement are both equal to 1.  
> 
> For the record, the problem arises from a conflict between two rules that
> must be applied for judging if this is a valid restriction:
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-particle-restrict
> (2.1) applied to the restrictions base type and 
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#rcase-RecurseAsIfGroup
> applied to the restricted type.  (Xerces' reporting of
> rcase-RecurseLax.2 and derivation-ok-restriction.5.4.2 is somewhat
> misleading.)  A good discussion of the problem can be found on w3c's
> xmlschema-dev list in a thread that starts with
> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Oct/0097.html.
> I believe the first mention of the problem was by Simon Cox in 
> http://www.stylusstudio.com/SSDN/default.asp?action=9&read=2948&fid=23&FirstTopic=1&LastTopic=9999
> in the context of the Geography Markup Language (GML) which employs 
> the same pattern.
> 
> The good news is that there is a work around.  This was worked out for
> GML and is described in 
> http://lists.w3.org/Archives/Public/xmlschema-dev/2004Oct/0103.html.
> 
> BTW, I think there are some other compliance issues that need being
> looked at.  More on that later.  
> 
> cheers,
> Ray
> 
> 
--------------------------------------------------------------------------
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 at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------