jaxp
  1. jaxp
  2. JAXP-44

If multiple schemas contain same targetnamespace, only the first one is used in schema validation

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      44

      Description

      If Schema is constructed with multiple schema files and they share the same
      targetnamespace, only the first is used for schema validation. This is a serious
      problem and limits web services schema validation.

      Attaching a test case that exhibits this behaviour. It has two runs to exhibit
      this issue.

        Activity

        jitu created issue -
        Hide
        jitu added a comment -

        Created an attachment (id=13)
        test case

        Show
        jitu added a comment - Created an attachment (id=13) test case
        Hide
        Santiago Pericas-Geertsen added a comment -

        According to the documentation for,

        http://java.sun.com/javase/6/docs/api/javax/xml/validation/SchemaFactory.html#newSchema
        (javax.xml.transform.Source[])

        The use of this method is equivalent to creating a single schema with a different targetns (and no
        components) where all the other schemas are imported. In this case this would be equivalent to:

        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="foo"
        elementFormDefault="qualified">

        <xsd:import schemaLocation="schema1.xsd" namespace="tns"/>
        <xsd:import schemaLocation="schema2.xsd" namespace="tns"/>

        </xsd:schema>

        If you use this single schema, you'd get a similar error. I believe processor behavior for the case when
        multiple imports of the same target namespace are present is implementation dependent. This is way
        I'm not convinced there's a problem here.

        Show
        Santiago Pericas-Geertsen added a comment - According to the documentation for, http://java.sun.com/javase/6/docs/api/javax/xml/validation/SchemaFactory.html#newSchema (javax.xml.transform.Source[]) The use of this method is equivalent to creating a single schema with a different targetns (and no components) where all the other schemas are imported. In this case this would be equivalent to: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="foo" elementFormDefault="qualified"> <xsd:import schemaLocation="schema1.xsd" namespace="tns"/> <xsd:import schemaLocation="schema2.xsd" namespace="tns"/> </xsd:schema> If you use this single schema, you'd get a similar error. I believe processor behavior for the case when multiple imports of the same target namespace are present is implementation dependent. This is way I'm not convinced there's a problem here.
        Hide
        jitu added a comment -

        It is not about imports, it's about having two documents that have the same
        targetnamespace. It just happened that my testcase is using imports. Some usecases:

        • It is possible to have multiple schema documents in the same targetnamespace.
        • A WSDL could have two <xsd:schema> elements with the same targetnamespace.

        I also see your point. The javadoc says "parsers may choose to ignore all but
        the first <import> for a given namespace, regardless of information provided in
        schemaLocation".

        Earlier Kohsuke said that this was bug. I will ask him to fill more information
        in this bug.

        Show
        jitu added a comment - It is not about imports, it's about having two documents that have the same targetnamespace. It just happened that my testcase is using imports. Some usecases: It is possible to have multiple schema documents in the same targetnamespace. A WSDL could have two <xsd:schema> elements with the same targetnamespace. I also see your point. The javadoc says "parsers may choose to ignore all but the first <import> for a given namespace, regardless of information provided in schemaLocation". Earlier Kohsuke said that this was bug. I will ask him to fill more information in this bug.
        Hide
        kohsuke added a comment -

        Santiago is right that the test case is semantically equivalent to the schema
        that has two <xsd:import>s to the same namespace URI.

        The real issue here is that the JAXP RI doesn't meet the user expectation with
        this kind of <import>ing two schemas of the same namespace URI. Whereas the
        expectation of people is for both schemas to be read, the JAXP RI only reads the
        first one and silently skips the second one.

        This behavior has been a source of confusion for many users in JAXB, too. The
        failure mode is often something like "no such element declaration tns:second",
        and people scratch their heads because it's clearly imported, as far as they can
        tell (and when they try other tools the schema works just fine.)

        Yes, we are aware that this behavior is allowed by the schema spec. But if
        that's the only criteria, the same schema spec allows you to ignore every
        <include> and <import> altogether, which is clearly unusable. So we need to
        design the behavior by factors beyond the schema spec compliance.

        I do realize this part of the JAXP RI is a real hair ball inherited from Xerces,
        so the fix might not be as easy as changing a few lines here and there, but I
        really think this behavior needs to be fixed.

        Show
        kohsuke added a comment - Santiago is right that the test case is semantically equivalent to the schema that has two <xsd:import>s to the same namespace URI. The real issue here is that the JAXP RI doesn't meet the user expectation with this kind of <import>ing two schemas of the same namespace URI. Whereas the expectation of people is for both schemas to be read, the JAXP RI only reads the first one and silently skips the second one. This behavior has been a source of confusion for many users in JAXB, too. The failure mode is often something like "no such element declaration tns:second", and people scratch their heads because it's clearly imported, as far as they can tell (and when they try other tools the schema works just fine.) Yes, we are aware that this behavior is allowed by the schema spec. But if that's the only criteria, the same schema spec allows you to ignore every <include> and <import> altogether, which is clearly unusable. So we need to design the behavior by factors beyond the schema spec compliance. I do realize this part of the JAXP RI is a real hair ball inherited from Xerces, so the fix might not be as easy as changing a few lines here and there, but I really think this behavior needs to be fixed.
        Hide
        Santiago Pericas-Geertsen added a comment -

        It turns out that Xerces does support this since 2.7.0, although we don't have support for in the
        SchemaFactory. Xerces supports this by setting the following property:

        "http://apache.org/xml/features/honour-all-schemaLocations"

        to true (it is false by default). I hope we can somehow change the SchemaFactory to support it as well.
        However, I still don't think this is a bug, so I'm updating the issue accordingly.

        Show
        Santiago Pericas-Geertsen added a comment - It turns out that Xerces does support this since 2.7.0, although we don't have support for in the SchemaFactory. Xerces supports this by setting the following property: "http://apache.org/xml/features/honour-all-schemaLocations" to true (it is false by default). I hope we can somehow change the SchemaFactory to support it as well. However, I still don't think this is a bug, so I'm updating the issue accordingly.
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 44 46728

          People

          • Assignee:
            jaxp-issues
            Reporter:
            jitu
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: