Xerces2-J
  1. Xerces2-J
  2. XERCESJ-1066

Restriction+choice+substitutionGroup error

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.6.2
    • Fix Version/s: 2.9.0
    • Labels:
      None
    • Environment:
      N/A

      Description

      When using a substitution group head in a choice, the head of the substitition group is not correctly treated as a choice.

      Given a choice of X and Y where X is the head of a group with the members X1, X2 and X3, the following SHOULD be true:

      Base = (X|Y)*

      ...according to clause 2.1 of Schema Component Constraint: Particle Valid (Restriction) <http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict> this should be interpreted as:

      Base = ((X|X1|X2|X3)|Y)*

      Therefore the following should be a valid restriction, but Xerces does not allow it:

      Restriction = ((X1|X2)|Y)*

      I am aware that some simplification of the choices is required by clause 2.2 of the above section, but this should not have the effect that it is.

      The following schema document demonstrates this:
      -----------------------------------------
      <?xml version="1.0"?>
      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      targetNamespace="urn:restrict" xmlns="urn:restrict"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

      <xsd:complexType name="base">
      <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
      <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="X"/>
      <xsd:element ref="Y"/>
      </xsd:choice>
      </xsd:restriction>
      </xsd:complexContent>
      </xsd:complexType>
      <xsd:element name="X"/>
      <xsd:element name="Y"/>
      <xsd:complexType name="restriction">
      <xsd:complexContent>
      <xsd:restriction base="base">
      <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:choice>
      <xsd:element ref="X1"/>
      <xsd:element ref="X2"/>
      </xsd:choice>
      <xsd:element ref="Y"/>
      </xsd:choice>
      </xsd:restriction>
      </xsd:complexContent>
      </xsd:complexType>
      <xsd:element name="X1" substitutionGroup="X"/>
      <xsd:element name="X2" substitutionGroup="X"/>

      </xsd:schema>

      1. patch1.txt
        0.9 kB
        Ignacio Hernandez-Ros
      2. patch2.txt
        6 kB
        Ignacio Hernandez-Ros
      3. patch2-2.txt
        6 kB
        Ignacio Hernandez-Ros
      4. bug1066-case0.xsd
        1 kB
        Ignacio Hernandez-Ros
      5. bug1066-case1.xsd
        0.8 kB
        Ignacio Hernandez-Ros
      6. bug1066-case2.xsd
        0.8 kB
        Ignacio Hernandez-Ros
      7. bug1066-case3.xsd
        1.0 kB
        Ignacio Hernandez-Ros
      8. patch3.txt
        11 kB
        Ignacio Hernandez-Ros

        Activity

        Martin Thomson created issue -
        Hide
        Martin Thomson added a comment -

        I should add that XSV (http://www.w3.org/2001/03/webdata/xsv) is happy with the above schema, while SQC (http://www.alphaworks.ibm.com/tech/xmlsqc) has the same problem.

        Show
        Martin Thomson added a comment - I should add that XSV ( http://www.w3.org/2001/03/webdata/xsv ) is happy with the above schema, while SQC ( http://www.alphaworks.ibm.com/tech/xmlsqc ) has the same problem.
        Hide
        Sandy Gao added a comment -

        > ...according to clause 2.1 of ...
        >
        > Base = ((X|X1|X2|X3)|Y)*

        The constraint you mentioned doesn't specify an order in which the involved elements appear in the choice model group, so it could very well be

        Base = ((X3|X2|X1|X)|Y)*

        > Restriction = ((X1|X2)|Y)*

        Because choice restriction is order-preserved, whether Restriction is valid is under-specified (depending on how you choose to order elements in Base).

        So technically speaking, Xerces doesn't have a bug here.

        Having said that, I agree that it's desired for Restriction to be a valid restriction of Base. I'll look into this to see whether it's easy to get the desired behavior.

        Show
        Sandy Gao added a comment - > ...according to clause 2.1 of ... > > Base = ((X|X1|X2|X3)|Y)* The constraint you mentioned doesn't specify an order in which the involved elements appear in the choice model group, so it could very well be Base = ((X3|X2|X1|X)|Y)* > Restriction = ((X1|X2)|Y)* Because choice restriction is order-preserved, whether Restriction is valid is under-specified (depending on how you choose to order elements in Base). So technically speaking, Xerces doesn't have a bug here. Having said that, I agree that it's desired for Restriction to be a valid restriction of Base. I'll look into this to see whether it's easy to get the desired behavior.
        Hide
        Martin Thomson added a comment -

        > The constraint you mentioned doesn't specify an order in which the involved elements appear in the choice model group, so it could very well be
        >
        > Base = ((X3|X2|X1|X)|Y)*

        I made the same comment to the XML Schema comments list. The working group are looking at making the appropriate changes to the specification. I hope to see some clarification in version 1.1 of XML Schema. It may be that the order constraint is lifted somehow, maybe only for substitution groups.

        Show
        Martin Thomson added a comment - > The constraint you mentioned doesn't specify an order in which the involved elements appear in the choice model group, so it could very well be > > Base = ((X3|X2|X1|X)|Y)* I made the same comment to the XML Schema comments list. The working group are looking at making the appropriate changes to the specification. I hope to see some clarification in version 1.1 of XML Schema. It may be that the order constraint is lifted somehow, maybe only for substitution groups.
        Hide
        Ignacio Hernandez-Ros added a comment -

        This bug may have some impact on how validation of XBRL ( http://www.xbrl.org ) generic linkbases is done so I've investigated how this bug could be fixed.
        Now, I've created a fix that works. How can I submit the fix to the source code?

        Show
        Ignacio Hernandez-Ros added a comment - This bug may have some impact on how validation of XBRL ( http://www.xbrl.org ) generic linkbases is done so I've investigated how this bug could be fixed. Now, I've created a fix that works. How can I submit the fix to the source code?
        Hide
        Michael Glavassevich added a comment -

        Hi Ignacio, you can add your patch as an attachment to this JIRA issue. Since I could not find a Contributor License Agreement (CLA) on file [1] for you, you'll need to answer the contributor questions from section 7.3 of the Xerces Project Charter, available here [2]. We require this information to accept bug fixes from individuals who have not signed a CLA.

        The questions/answers can just be added to this bug report.

        [1] http://www.apache.org/~jim/committers.html
        [2] http://xerces.apache.org/xerces2-j/charter.html

        Show
        Michael Glavassevich added a comment - Hi Ignacio, you can add your patch as an attachment to this JIRA issue. Since I could not find a Contributor License Agreement (CLA) on file [1] for you, you'll need to answer the contributor questions from section 7.3 of the Xerces Project Charter, available here [2] . We require this information to accept bug fixes from individuals who have not signed a CLA. The questions/answers can just be added to this bug report. [1] http://www.apache.org/~jim/committers.html [2] http://xerces.apache.org/xerces2-j/charter.html
        Hide
        Lucian Holland added a comment -

        I believe that this is a duplicate of https://issues.apache.org/jira/browse/XERCESJ-1032; FWIW I've submitted a patch against that issue... and there's a CLA on file for me already

        Show
        Lucian Holland added a comment - I believe that this is a duplicate of https://issues.apache.org/jira/browse/XERCESJ-1032 ; FWIW I've submitted a patch against that issue... and there's a CLA on file for me already
        Hide
        Ignacio Hernandez-Ros added a comment -

        CLA has been faxed. Two files must be patched.

        Show
        Ignacio Hernandez-Ros added a comment - CLA has been faxed. Two files must be patched.
        Ignacio Hernandez-Ros made changes -
        Field Original Value New Value
        Attachment patch1.txt [ 12341817 ]
        Attachment patch2.txt [ 12341818 ]
        Michael Glavassevich made changes -
        Assignee Sandy Gao [ sandygao@ca.ibm.com ]
        Hide
        Ignacio Hernandez-Ros added a comment -

        Lucian's comments regarding duplicate bug reports are right. Both patches solves the same kind of problems but using different strategies; Therefore I think both patches could be applied without any risk.

        Show
        Ignacio Hernandez-Ros added a comment - Lucian's comments regarding duplicate bug reports are right. Both patches solves the same kind of problems but using different strategies; Therefore I think both patches could be applied without any risk.
        Hide
        Sandy Gao added a comment -

        [Problem analysis]

        First of all, this bug is not a duplicate of 1032. After applying the patch provided in 1032, the 1032 test schema passes, but the schema attached to 1066 still fails.

        There are 2 problems in Xerces' current implementation. The first one is, as Lucian correctly pointed out in 1032, that the order of sub-group-expansion is not specified (more a problem in the spec, as I mentioned in the first comment to this bug).

        The second problem (what's really causing 1066) is that "pointless particle removal" happens before sub-group-expansion, as opposed to after, as specified in the spec.

        To be more specific about point 2 (and to correct what I said in the first comment). For the schema attached above, after removal and expansion:
        Base = ((X|X1|X2|X3)|Y)*
        Restriction = (X1|X2|Y)*

        Note that Base has nested choice groups and Restriction doesn't. Now when the "RecurseLax" rule is invoked, the 3 particles in Restriction need to map to 2 particles in the Base. Never possible, hence rejected.

        So to me, the right fix needs to contain 2 parts:
        1. expand sub-groups before pointless particle removal
        2. disregard ordering for choices resulted from sub-group expansion.

        [Patch analysis - 1032]

        1032 patch sorts particles resulted from sub-group-expansion. This partially fixes the ordering problem, but not completely. It works when both base and restriction use sub-groups. After both are sorted, the "complete mapping" rule can be applied. But it doesn't work when one of the types uses sub-group and the other doesn't, because the type that doesn't use sub-group may have elements in arbitrary order.

        Knowing the sorting strategy may help schema designers: when writing choices, try to sort them. This may or may not be appropriate for certain schema authors/designs, and may or may not work for different languages.

        Overall, 1032 is a safe fix, it improves things, though doesn't fix the problem entirely. I'm willing to apply it unless a better/more complete solution is found.

        [Patch analysis - 1066]

        On the surface, Ignacio's patch works perfectly: both schemas from 1032 and 1066 are now accepted. But careful looking at the details reveals some rather serious problems.

        For the 1032 schema, this patch works because both sub-groups are turned into this special MODELGROUP_SUBSTITUTIONGROUP and are handled specially (without worrying about the order).

        For the 1066 schema, it works because it treats X1 (the element) as restricting the sub-group (X|X1|X2|X3) and X2 as restriction (X|X1|X2|X3) again. I would consider this as "works by luck".

        The reason it's "luck" is because there are some schemas (valid and invalid) that this patch will give the wrong answer.

        Case 1:

        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:restrict" xmlns="urn:restrict"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

        <xsd:element name="X"/>
        <xsd:element name="X1" substitutionGroup="X"/>

        <xsd:complexType name="base">
        <xsd:sequence>
        <xsd:element ref="X" minOccurs="0"/>
        </xsd:sequence>
        </xsd:complexType>

        <xsd:complexType name="restriction">
        <xsd:complexContent>
        <xsd:restriction base="base">
        <xsd:choice minOccurs="0">
        <xsd:element ref="X1"/>
        </xsd:choice>
        </xsd:restriction>
        </xsd:complexContent>
        </xsd:complexType>

        </xsd:schema>

        After expansion and removal,
        Base = (X|X1|)?
        Restriction = (X1|)?

        (The last '|' is just to indicate it's a choice.)

        The spec is clear that this is a valid restriction (RecurseLax). But 1066 patch would reject it, because now dType=choice and bType=subgroup, which is not handled by the big switch.

        Case 2:

        Similar to Case 1, but change the <choice> in "restriction" to <sequence>, it should still be valid (MapAndSum). But again, 1066 patch rejects it, for the same reason.

        Case 3:

        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:restrict" xmlns="urn:restrict"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

        <xsd:element name="X"/>
        <xsd:element name="Y"/>
        <xsd:element name="Z"/>

        <xsd:complexType name="base">
        <xsd:choice>
        <xsd:choice minOccurs="0">
        <xsd:element ref="X"/>
        <xsd:element ref="Y"/>
        </xsd:choice>
        <xsd:element ref="Z"/>
        </xsd:choice>
        </xsd:complexType>

        <xsd:complexType name="restriction">
        <xsd:complexContent>
        <xsd:restriction base="base">
        <xsd:choice>
        <xsd:choice>
        <xsd:element ref="X"/>
        <xsd:element ref="Y"/>
        </xsd:choice>
        <xsd:element ref="Z"/>
        </xsd:choice>
        </xsd:restriction>
        </xsd:complexContent>
        </xsd:complexType>

        </xsd:schema>

        However valid this looks like (I just changed something from optional to mandatory), this is actually invalid in schema 1.0. (Note that schema 1.1 [1] plans to replace the entire Particle Valid (Restriction) rule with a supposedly simple statement: it's a restriction as long as it accepts a subset.)

        Base = ((X|Y|)?|Z)
        Restriction = (X|Y|Z)

        "X" and "Y" in restriction can not both map to (X|Y) in base, because RecurseLax requires an order-preserving mapping. So this should be invalid, but 1066 patch says it's valid. What causes this to fail to produce the correct result is actually the same as what was introduced to make the original 1066 test case happy. Namely the change in the method "checkRecurseLax" to reuse the base particle.

        Though not working as a charm, this patch actually involves some creative thinking and is somewhat similar to some of my thoughts back in 2005 when 1066 was first opened (see below). Thanks for the effort and do keep trying. I sincerely hope that you beat me in finding the perfect solution.

        [My Attempts]

        My first attempt in 2005 was similar to your approaches in different aspects. I mark sub-group choices as special, and have a special method to handle the RecurseLax case when either choice came from a sub-group. This does a better job than the 1032 patch, because the special method discards order entirely, instead of using a specific order.

        This attempt would have fixed 1032, but my focus was 1066 and it didn't work for 1066, because of the reason I mentioned earlier: expansion happened after removal.

        My second attempt was to move the expansion to happen before removal, but encounter a big problem where expansion and removal don't seem to work together happily. Consider a choice

        (A|B|C|D)

        where B has X in its sub-group and D has Y in its sub-group. After expansion/removal, it becomes

        (A|B|X|C|D|Y)

        Now we have to remember that the order between B and X doesn't matter, neither does that between D and Y. But the order does matter between A and B/X and so on.

        This is where I stopped (it seemed too difficult to solve when no one was pressing ).

        Ouch, it takes almost an entire day to analyze the problems (again), look at the patches, and re-gather my thoughts from last year, and of course, write this long comment. I'm glad that I'm writing things down this time so that I don't have to go through the same process again in the future. I will definitely give it some more thoughts. The least we can do is to commit Lucian's patch (or my attempt 1). Or to make expansion happen before removal + Lucian's patch. Though not complete, the latter should make both test cases from 1032 and 1066 happy.

        [1] http://www.w3.org/TR/xmlschema11-1/#cos-content-act-restrict

        Show
        Sandy Gao added a comment - [Problem analysis] First of all, this bug is not a duplicate of 1032. After applying the patch provided in 1032, the 1032 test schema passes, but the schema attached to 1066 still fails. There are 2 problems in Xerces' current implementation. The first one is, as Lucian correctly pointed out in 1032, that the order of sub-group-expansion is not specified (more a problem in the spec, as I mentioned in the first comment to this bug). The second problem (what's really causing 1066) is that "pointless particle removal" happens before sub-group-expansion, as opposed to after , as specified in the spec. To be more specific about point 2 (and to correct what I said in the first comment). For the schema attached above, after removal and expansion: Base = ((X|X1|X2|X3)|Y)* Restriction = (X1|X2|Y)* Note that Base has nested choice groups and Restriction doesn't. Now when the "RecurseLax" rule is invoked, the 3 particles in Restriction need to map to 2 particles in the Base. Never possible, hence rejected. So to me, the right fix needs to contain 2 parts: 1. expand sub-groups before pointless particle removal 2. disregard ordering for choices resulted from sub-group expansion. [Patch analysis - 1032] 1032 patch sorts particles resulted from sub-group-expansion. This partially fixes the ordering problem, but not completely. It works when both base and restriction use sub-groups. After both are sorted, the "complete mapping" rule can be applied. But it doesn't work when one of the types uses sub-group and the other doesn't, because the type that doesn't use sub-group may have elements in arbitrary order. Knowing the sorting strategy may help schema designers: when writing choices, try to sort them. This may or may not be appropriate for certain schema authors/designs, and may or may not work for different languages. Overall, 1032 is a safe fix, it improves things, though doesn't fix the problem entirely. I'm willing to apply it unless a better/more complete solution is found. [Patch analysis - 1066] On the surface, Ignacio's patch works perfectly: both schemas from 1032 and 1066 are now accepted. But careful looking at the details reveals some rather serious problems. For the 1032 schema, this patch works because both sub-groups are turned into this special MODELGROUP_SUBSTITUTIONGROUP and are handled specially (without worrying about the order). For the 1066 schema, it works because it treats X1 (the element) as restricting the sub-group (X|X1|X2|X3) and X2 as restriction (X|X1|X2|X3) again. I would consider this as "works by luck". The reason it's "luck" is because there are some schemas (valid and invalid) that this patch will give the wrong answer. Case 1: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:restrict" xmlns="urn:restrict" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:element name="X"/> <xsd:element name="X1" substitutionGroup="X"/> <xsd:complexType name="base"> <xsd:sequence> <xsd:element ref="X" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="restriction"> <xsd:complexContent> <xsd:restriction base="base"> <xsd:choice minOccurs="0"> <xsd:element ref="X1"/> </xsd:choice> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:schema> After expansion and removal, Base = (X|X1|)? Restriction = (X1|)? (The last '|' is just to indicate it's a choice.) The spec is clear that this is a valid restriction (RecurseLax). But 1066 patch would reject it, because now dType=choice and bType=subgroup, which is not handled by the big switch. Case 2: Similar to Case 1, but change the <choice> in "restriction" to <sequence>, it should still be valid (MapAndSum). But again, 1066 patch rejects it, for the same reason. Case 3: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:restrict" xmlns="urn:restrict" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:element name="X"/> <xsd:element name="Y"/> <xsd:element name="Z"/> <xsd:complexType name="base"> <xsd:choice> <xsd:choice minOccurs="0"> <xsd:element ref="X"/> <xsd:element ref="Y"/> </xsd:choice> <xsd:element ref="Z"/> </xsd:choice> </xsd:complexType> <xsd:complexType name="restriction"> <xsd:complexContent> <xsd:restriction base="base"> <xsd:choice> <xsd:choice> <xsd:element ref="X"/> <xsd:element ref="Y"/> </xsd:choice> <xsd:element ref="Z"/> </xsd:choice> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:schema> However valid this looks like (I just changed something from optional to mandatory), this is actually invalid in schema 1.0. (Note that schema 1.1 [1] plans to replace the entire Particle Valid (Restriction) rule with a supposedly simple statement: it's a restriction as long as it accepts a subset.) Base = ((X|Y|)?|Z) Restriction = (X|Y|Z) "X" and "Y" in restriction can not both map to (X|Y) in base, because RecurseLax requires an order-preserving mapping. So this should be invalid, but 1066 patch says it's valid. What causes this to fail to produce the correct result is actually the same as what was introduced to make the original 1066 test case happy. Namely the change in the method "checkRecurseLax" to reuse the base particle. Though not working as a charm, this patch actually involves some creative thinking and is somewhat similar to some of my thoughts back in 2005 when 1066 was first opened (see below). Thanks for the effort and do keep trying. I sincerely hope that you beat me in finding the perfect solution. [My Attempts] My first attempt in 2005 was similar to your approaches in different aspects. I mark sub-group choices as special, and have a special method to handle the RecurseLax case when either choice came from a sub-group. This does a better job than the 1032 patch, because the special method discards order entirely, instead of using a specific order. This attempt would have fixed 1032, but my focus was 1066 and it didn't work for 1066, because of the reason I mentioned earlier: expansion happened after removal. My second attempt was to move the expansion to happen before removal, but encounter a big problem where expansion and removal don't seem to work together happily. Consider a choice (A|B|C|D) where B has X in its sub-group and D has Y in its sub-group. After expansion/removal, it becomes (A|B|X|C|D|Y) Now we have to remember that the order between B and X doesn't matter, neither does that between D and Y. But the order does matter between A and B/X and so on. This is where I stopped (it seemed too difficult to solve when no one was pressing ). Ouch, it takes almost an entire day to analyze the problems (again), look at the patches, and re-gather my thoughts from last year, and of course, write this long comment. I'm glad that I'm writing things down this time so that I don't have to go through the same process again in the future. I will definitely give it some more thoughts. The least we can do is to commit Lucian's patch (or my attempt 1). Or to make expansion happen before removal + Lucian's patch. Though not complete, the latter should make both test cases from 1032 and 1066 happy. [1] http://www.w3.org/TR/xmlschema11-1/#cos-content-act-restrict
        Hide
        Lucian Holland added a comment -

        Woah - that's practically a dissertation! Many, many thanks for the careful analysis and write-up Sandy. I'm quite busy at the moment, but when I get a moment I'd be happy to have another look at this (it's a challenge now!). In the meantime I'm sure everyone would be glad of whatever interim, partial fix you think makes sense, using whatever combination of patches/attempts so far suggested seems appropriate... And then we can all go and join the queue of people waiting to ask HT what they ever did to him

        Show
        Lucian Holland added a comment - Woah - that's practically a dissertation! Many, many thanks for the careful analysis and write-up Sandy. I'm quite busy at the moment, but when I get a moment I'd be happy to have another look at this (it's a challenge now!). In the meantime I'm sure everyone would be glad of whatever interim, partial fix you think makes sense, using whatever combination of patches/attempts so far suggested seems appropriate... And then we can all go and join the queue of people waiting to ask HT what they ever did to him
        Hide
        Ignacio Hernandez-Ros added a comment -

        Substituties previous patch-2.txt file. patch-1.txt must still be appied to compile this patch.

        Show
        Ignacio Hernandez-Ros added a comment - Substituties previous patch-2.txt file. patch-1.txt must still be appied to compile this patch.
        Ignacio Hernandez-Ros made changes -
        Attachment patch2-2.txt [ 12341955 ]
        Hide
        Ignacio Hernandez-Ros added a comment -

        WOW!!! I'm also impressed about how this is moving. I've patched my second patch in order to resolve case1 and case 2 according to the expected result. Both schemas are now considered valid.

        I've a small question regarding case3. The XSV 2.10-1 validator considers it as a valid schema; and after applying patch2-2.txt xerces considers it valid as well.

        II'm going to test a new version of xerces with Lucian's patch and my patch working together. I don't think there is a perfect solution for this really complex problem. I'll be happy if we can find a solution that is closer to the XML Schema spec than the one we have now even it is not perfect.

        Thank you very much for your time and efforts.

        Show
        Ignacio Hernandez-Ros added a comment - WOW!!! I'm also impressed about how this is moving. I've patched my second patch in order to resolve case1 and case 2 according to the expected result. Both schemas are now considered valid. I've a small question regarding case3. The XSV 2.10-1 validator considers it as a valid schema; and after applying patch2-2.txt xerces considers it valid as well. II'm going to test a new version of xerces with Lucian's patch and my patch working together. I don't think there is a perfect solution for this really complex problem. I'll be happy if we can find a solution that is closer to the XML Schema spec than the one we have now even it is not perfect . Thank you very much for your time and efforts.
        Hide
        Ignacio Hernandez-Ros added a comment -

        I've spent some time looking at the code and trying to figure out a way to made case 0,1 and 2 valid and case 3 invalid. I have not found a solution yet and I know this will take more time than expected. In the meantime, Lucian's patch works really well solving some of the cases and I want to recomend you to apply that patch for the next release of xerces.

        Show
        Ignacio Hernandez-Ros added a comment - I've spent some time looking at the code and trying to figure out a way to made case 0,1 and 2 valid and case 3 invalid. I have not found a solution yet and I know this will take more time than expected. In the meantime, Lucian's patch works really well solving some of the cases and I want to recomend you to apply that patch for the next release of xerces.
        Ignacio Hernandez-Ros made changes -
        Attachment bug1066-case2.xsd [ 12342268 ]
        Attachment bug1066-case1.xsd [ 12342267 ]
        Attachment bug1066-case0.xsd [ 12342266 ]
        Ignacio Hernandez-Ros made changes -
        Attachment bug1066-case3.xsd [ 12342269 ]
        Hide
        Ignacio Hernandez-Ros added a comment -

        I hope this is the definitive patch. It incorporates Lucian Holland patch and fixed code to deal use use cases 0 valid, 1 valid, 2 valid and 3 as invalid.

        Show
        Ignacio Hernandez-Ros added a comment - I hope this is the definitive patch. It incorporates Lucian Holland patch and fixed code to deal use use cases 0 valid, 1 valid, 2 valid and 3 as invalid.
        Ignacio Hernandez-Ros made changes -
        Attachment patch3.txt [ 12345213 ]
        Hide
        Ignacio Hernandez-Ros added a comment -

        Hello,

        I've uploaded a new patch. (patch3) I hope this will be the definitive one.

        Reading Sandy Gao comments I've implemented a simple change. The particleValidRestriction function returns a boolean value indicating if expansion has occur. In that case recurseLax goes back one element because ordering is not important.

        Clever and simpler than I would expect.

        patch3.txt incorporates also Lucian Holland patch to sort the particles.

        Show
        Ignacio Hernandez-Ros added a comment - Hello, I've uploaded a new patch. (patch3) I hope this will be the definitive one. Reading Sandy Gao comments I've implemented a simple change. The particleValidRestriction function returns a boolean value indicating if expansion has occur. In that case recurseLax goes back one element because ordering is not important. Clever and simpler than I would expect. patch3.txt incorporates also Lucian Holland patch to sort the particles.
        Hide
        Sandy Gao added a comment -

        Ignacio. Your patch looks good and I've just applied it. Thanks for all the effort.

        Show
        Sandy Gao added a comment - Ignacio. Your patch looks good and I've just applied it. Thanks for all the effort.
        Sandy Gao made changes -
        Resolution Fixed [ 1 ]
        Fix Version/s 2.9.0 [ 12312170 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Mark Thomas made changes -
        Workflow jira [ 41848 ] Default workflow, editable Closed status [ 12575982 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12575982 ] jira [ 12598914 ]

          People

          • Assignee:
            Sandy Gao
            Reporter:
            Martin Thomson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development