complexContent restriction: is it XSD 1.0 or Xerces causing this behavior change? - xsd

Question

Here is a small schema, and a sample XML file, that will validate successfully at the Xerces-J online validation service if XSD version 1.1 is selected, but not XSD 1.0.
With 1.0 selected, the schema itself is rejected, as invalidly deriving t2 from t1. (The intent is that t1 allows an optional thing and some stuff, and t2 is a restriction that keeps the stuff but forbids the thing.)
The exact complaint from Xerces-J with 1.0 selected is:
[Error] foo.xsd:19:28:rcase-Recurse.1: Group's occurrence range, (0,unbounded), is not a valid restriction of base group's occurrence range, (1,1).
[Error] foo.xsd:19:28:derivation-ok-restriction.5.4.2: Error for type 't2'. The particle of the type is not a valid restriction of the particle of the base.
I think what happens is the containing <sequence> in t2 gets considered "pointless" (2.2.2.2.1 here) because it now has only one child, but the corresponding <sequence> in t1 is not "pointless" because it has two children, and the derivation checker is trying to match the minOccurs and maxOccurs of t2's <group> against those of t1's <sequence>. Somehow, the checker for XSD 1.1 manages to be smarter than that.
So my question (ok, two questions):
Is this behavior in 1.0 an inherent known limit of XSD 1.0 that the derivation rules in 1.1 were updated to fix, or is it a limit of the Xerces-J implementation of 1.0? Does anybody have a 1.0 implementation that accepts this schema?
Given the continued deployment of tools that use 1.0, does anyone know an alternate way to write this schema that will work in 1.0? (I can make this example work by losing the <group> and inlining the <stuff> element both places, but that's not a plan if the real-life group has more than one child).
Edit: even the inlining workaround is unavailing if the element heads a substitution group. That gets reified here as a <choice> group, which again has its minOccurs and maxOccurs mismatch those of the base type's <sequence>.
foo.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="foo:bar"
xmlns="foo:bar">
<xs:group name="stuffGroup">
<xs:sequence>
<xs:element name="stuff"/>
</xs:sequence>
</xs:group>
<xs:complexType name="t1">
<xs:sequence>
<xs:element name="thing" minOccurs="0"/>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="t2">
<xs:complexContent>
<xs:restriction base="t1">
<xs:sequence>
<xs:group ref="stuffGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="a" type="t2"/>
</xs:schema>
foo.xml:
<a xmlns='foo:bar'/>

Answer 1

The Microsoft .NET XSD 1.0 based schema validator rejects your schema with an error in line 19 saying (citing first the German message I get from VS): "
Warnung Ungültige Partikelableitung durch Einschränkung - 'Gemäß All:All,Sequence:Sequence -- Recurse-Regel 1 oder Choice:Choice -- RecurseLax ist der Bereich des abgeleiteten Partikels keine gültige Einschränkung des Basispartikelbereichs.'." which I would translate roughly as "Warning invalid particle inference by restriction - according to All:All,Sequence:Sequence -- Recurse-rule 1 oder Choice:Choice -- RecurseLax is the domain of the inferred particle no valid restriction of the base particle domain".
Xmllint ("xmllint: using libxml version 20910"), on the other hand, when trying to validate the sample against the schema with e.g. command line options --schema schema1.xsd sample1.xml reports:
<?xml version="1.0"?>
<a xmlns="foo:bar"/>
sample1.xml validates
I will need to dig deeper in the schema specs the judge what is the right behaviour.