Uploaded image for project: 'Xerces2-J'
  1. Xerces2-J
  2. XERCESJ-1287

Restriction of a sequence fails if base sequence has non-unity cardinality and particle in restriction uses a substition group

    XMLWordPrintableJSON

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.

      Attachments

        1. patch-1287.txt
          2 kB
          Oliver Waeldrich
        2. restrict3.xsd
          2 kB
          Martin Thomson

        Activity

          People

            sandygao@ca.ibm.com Sandy Gao
            emptyweevil Martin Thomson
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: