xerces-j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Waeldrich (Updated) (JIRA)" <xerces-j-...@xml.apache.org>
Subject [jira] [Updated] (XERCESJ-1287) Restriction of a sequence fails if base sequence has non-unity cardinality and particle in restriction uses a substition group
Date Tue, 24 Jan 2012 12:12:39 GMT

     [ https://issues.apache.org/jira/browse/XERCESJ-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Oliver Waeldrich updated XERCESJ-1287:

    Attachment: patch-1287.txt

patch for fixing the concurrencies for substitution groups in xsd validation
> Restriction of a sequence fails if base sequence has non-unity cardinality and particle
in restriction uses a substition group
> ------------------------------------------------------------------------------------------------------------------------------
>                 Key: XERCESJ-1287
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-1287
>             Project: Xerces2-J
>          Issue Type: Bug
>          Components: XML Schema 1.0 Structures
>    Affects Versions: 2.9.1
>         Environment: Windows, Java 1.5.0-b64
>            Reporter: Martin Thomson
>            Assignee: Sandy Gao
>         Attachments: patch-1287.txt, restrict3.xsd
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org

View raw message