jaxb
  1. jaxb
  2. JAXB-796

xjc fails when schema declares attribute twice (through imports)

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2.2
    • Fix Version/s: None
    • Component/s: xjc
    • Labels:
      None

      Description

      I have a main schema that imports several other schemas. Two of these other schemas use xlink, and both import a schema for xlink containing a declaration for xlink:href like

      <xs:attribute name="href" type="xs:anyURI"/>

      As all the declarations use the same type, this is allowed in XML Schema and I have no problem validating my XML instances against my main schema. However, when I attempt to compile my main schema using xjc, it fails with the error

      [ERROR] 'href' is already defined
      line 11 of file:/home/bas/data/mathml2/common/xlink-href.xsd

      [ERROR] (related to above error) the first definition appears here
      line 18 of file:/home/bas/xsd/xlink.xsd

      Failed to parse a schema.

        Activity

        Hide
        Martin Matula added a comment -

        Martin, please evaluate.

        Show
        Martin Matula added a comment - Martin, please evaluate.
        Hide
        laune added a comment -

        I'm not an expert, but the XML Schema doc contains this, where item #2 could be relevant.

        3.15.6 Constraints on Schemas as a Whole

        All schemas (see Schemas as a Whole (§3.15)) must satisfy the following constraint.
        Schema Component Constraint: Schema Properties Correct
        All of the following must be true:
        1 The values of the properties of a schema must be as described in the property tableau in The Schema Itself (§3.15.1), modulo the impact of Missing Sub-components (§5.3);
        2 Each of the

        {type definitions}

        ,

        {element declarations}

        ,

        {attribute group definitions}

        ,

        {model group definitions}

        and

        {notation declarations}

        must not contain two or more schema components with the same

        {name}

        and

        {target namespace}

        .

        In any case, the fact that an XML validates against a possibly (slightly) defective XML schema is no proof. Unmarshalling of the XML schema may very well tolerate such a duplicity.

        Also, fixing this for attributes would imply that it also has to be fixed for XML Schema elements, types etc.

        Show
        laune added a comment - I'm not an expert, but the XML Schema doc contains this, where item #2 could be relevant. 3.15.6 Constraints on Schemas as a Whole All schemas (see Schemas as a Whole (§3.15)) must satisfy the following constraint. Schema Component Constraint: Schema Properties Correct All of the following must be true: 1 The values of the properties of a schema must be as described in the property tableau in The Schema Itself (§3.15.1), modulo the impact of Missing Sub-components (§5.3); 2 Each of the {type definitions} , {element declarations} , {attribute group definitions} , {model group definitions} and {notation declarations} must not contain two or more schema components with the same {name} and {target namespace} . In any case, the fact that an XML validates against a possibly (slightly) defective XML schema is no proof. Unmarshalling of the XML schema may very well tolerate such a duplicity. Also, fixing this for attributes would imply that it also has to be fixed for XML Schema elements, types etc.
        Hide
        basdebakker14 added a comment -

        Please also see section 4.2.3 on imports, particularly the note at the end:

        Note: The above is carefully worded so that multiple <import>ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.15.6), but applications are allowed, indeed encouraged, to avoid <import>ing the same schema document more than once to forestall the necessity of establishing identity component by component.

        Show
        basdebakker14 added a comment - Please also see section 4.2.3 on imports, particularly the note at the end: Note: The above is carefully worded so that multiple <import>ing of the same schema document will not constitute a violation of clause 2 of Schema Properties Correct (§3.15.6), but applications are allowed, indeed encouraged, to avoid <import>ing the same schema document more than once to forestall the necessity of establishing identity component by component.
        Hide
        laune added a comment -

        It's very reasonable that "multiple <import>ing of the same schema document" should not require "establishing identity component by component".

        But, looking at the error messages provided in the original issue statement, I see that the URIs of the two XML schemas are different, which makes them different, even when they, compared as text files, would not be different.

        If the two xsd texts /home/bas/data/mathml2/common/xlink-href.xsd and /home/bas/xsd/xlink.xsd are indeed textually equal, it would be interesting to learn whether changing one of the imports to the same URI would solve the problem. (This would show whether the cited paragraph from 4.2.3 has been considered in the implementation of the XML Schema parser used in JAXB's xjc.)

        Show
        laune added a comment - It's very reasonable that "multiple <import>ing of the same schema document" should not require "establishing identity component by component". But, looking at the error messages provided in the original issue statement, I see that the URIs of the two XML schemas are different, which makes them different , even when they, compared as text files, would not be different. If the two xsd texts /home/bas/data/mathml2/common/xlink-href.xsd and /home/bas/xsd/xlink.xsd are indeed textually equal, it would be interesting to learn whether changing one of the imports to the same URI would solve the problem. (This would show whether the cited paragraph from 4.2.3 has been considered in the implementation of the XML Schema parser used in JAXB's xjc.)
        Hide
        basdebakker14 added a comment -

        The note implies that if you would just import the same document twice (also allowed, though not encouraged), you would need to establish identity component by component. This suggests that in other cases you need to do this anyway, as the text of the specification itself (before the note) makes no difference between importing the same or different schema documents.

        But instead of discussing the note, let's go back to the actual specification text. It says:

        <quote>
        The ·schema components· (that is

        {type definitions}

        ,

        {attribute declarations}

        ,

        {element declarations}

        ,

        {attribute group definitions}

        ,

        {model group definitions}

        ,

        {notation declarations}

        ) of a schema corresponding to a <schema> element information item with one or more <import> element information items must include not only definitions or declarations corresponding to the appropriate members of its [children], but also, for each of those <import> element information items for which clause 2 above is satisfied, a set of ·schema components· identical to all the ·schema components· of I.
        </quote>

        where "I" is the imported schema. It does not say to simply include the schema components of I in the importing schema. So if my imported schema contains a schema component for

        <xs:attribute name="href" type="xs:anyURI"/>

        my main schema must also contain a component for this item. If I now import another schema with an identical component, it simply implies again that my main schema must contain such a component. But as it already does contain such a component, my main schema is simply not modified by the second import.

        Strictly speaking (read the spec, this does not follow from the above) the implementation can simply ignore all but the first import for a given namespace. This would also solve my problem. But as a quality of implementation issue, I think it would be more useful to read all the imported schema documents and ignore identical declarations.

        Show
        basdebakker14 added a comment - The note implies that if you would just import the same document twice (also allowed, though not encouraged), you would need to establish identity component by component. This suggests that in other cases you need to do this anyway, as the text of the specification itself (before the note) makes no difference between importing the same or different schema documents. But instead of discussing the note, let's go back to the actual specification text. It says: <quote> The ·schema components· (that is {type definitions} , {attribute declarations} , {element declarations} , {attribute group definitions} , {model group definitions} , {notation declarations} ) of a schema corresponding to a <schema> element information item with one or more <import> element information items must include not only definitions or declarations corresponding to the appropriate members of its [children] , but also, for each of those <import> element information items for which clause 2 above is satisfied, a set of ·schema components· identical to all the ·schema components· of I. </quote> where "I" is the imported schema. It does not say to simply include the schema components of I in the importing schema. So if my imported schema contains a schema component for <xs:attribute name="href" type="xs:anyURI"/> my main schema must also contain a component for this item. If I now import another schema with an identical component, it simply implies again that my main schema must contain such a component. But as it already does contain such a component, my main schema is simply not modified by the second import. Strictly speaking (read the spec, this does not follow from the above) the implementation can simply ignore all but the first import for a given namespace. This would also solve my problem. But as a quality of implementation issue, I think it would be more useful to read all the imported schema documents and ignore identical declarations.
        Hide
        Martin Grebac added a comment -

        Hi, please submit a full testcase, thanks.

        Show
        Martin Grebac added a comment - Hi, please submit a full testcase, thanks.
        Hide
        basdebakker14 added a comment -

        To test:
        1) Unpack jaxbtest.zip.
        2) Go to jaxbtest directory.
        3) xjc main.xsd

        Expected result: compilation succeeds.
        Actual result: compilation fails with error below

        parsing a schema...
        [ERROR] 'href' is already defined
        line 4 of file:/home/bas/jaxbtest/xlink2.xsd

        [ERROR] (related to above error) the first definition appears here
        line 4 of file:/home/bas/jaxbtest/xlink1.xsd

        Failed to parse a schema.

        Show
        basdebakker14 added a comment - To test: 1) Unpack jaxbtest.zip. 2) Go to jaxbtest directory. 3) xjc main.xsd Expected result: compilation succeeds. Actual result: compilation fails with error below parsing a schema... [ERROR] 'href' is already defined line 4 of file:/home/bas/jaxbtest/xlink2.xsd [ERROR] (related to above error) the first definition appears here line 4 of file:/home/bas/jaxbtest/xlink1.xsd Failed to parse a schema.
        Hide
        basdebakker14 added a comment -

        This was marked incomplete with the request for a testcase. As I've added the testcase, I assume the "incomplete" tag no longer applies.

        Show
        basdebakker14 added a comment - This was marked incomplete with the request for a testcase. As I've added the testcase, I assume the "incomplete" tag no longer applies.

          People

          • Assignee:
            Martin Grebac
            Reporter:
            basdebakker14
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: