Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.9.1
-
None
-
None
-
Windows, Java 1.5.0-b64
Description
Restriction fails with rcase-Recurse.2 when:
- the sequence in the base has non-unity cardinality**
- one of the particles in the restriction has non-unity cardinality
- the particles in the restriction with non-unity cardinality is in the substitution group of the corresponding particle in the base
- there is more than one particle in the sequence in the restriction
-
- I've only done simple tests. I can confirm that this occurs if either minOccurs="0" or maxOccurs=">1"; so I'm assuming that the condition is (minOccurs != 1 || maxOccurs != 1). It could just be if (minOccurs != maxOccurs).
The list of requirements for this bug are so long it might seem a wonder that anyone would encounter it, but looking at an example, it seems a little less improbable.
Given the following elements:
<xs:element name="X"/>
<xs:element name="X_R" substitutionGroup="X"/>
<xs:element name="Y"/>
And a base type defined as a sequence with minOccurs="0":
base = (X?,Y)?
The following restrictions are accepted with no complaints:
restriction_equal = (X?,Y)?
restriction_ok = (X_R,Y)?
But if the restriction includes a particle with minOccurs="0" AND elements in a substitution group, the restriction fails:
restriction_bad1 = (X_R?,Y)?
restriction_bad2 = (X_R?,Y)
The position within the sequence doesn't appear to matter, but the problem doesn't arise with only one element in the sequence. Changing the cardinality of the enclosing sequence through restriction doesn't seem to change anything.
This may have the same cause as issue 1285, but I can't figure out a workaround for this one. The thought occurs that the fix to issue 1066 might be involved.