jaxp
  1. jaxp
  2. JAXP-41

SchemaFactory fails to parse a seemingly valid schema

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      41

      Description

      A JAXB user discovered a bug in the JAXP RI. The following code reproduces the
      problem:

      public static void main(String[] args) throws SAXException,
      MalformedURLException

      { SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI).newSchema( new URL("http://schemas.opengis.net/csw/2.0.1/CSW-discovery.xsd")); }

      This fails with the error "src-resolve: Cannot resolve the name
      'ows:ServiceType' to a 'type definition' component."

      If you look at the schema, it contains the import line, and this imported schema
      seems to define the ServiceType type.

      <xsd:import namespace="http://www.opengis.net/ows"
      schemaLocation="../../ows/1.0.0/owsGetCapabilities.xsd"/>

      See the JAXB issue https://jaxb.dev.java.net/issues/show_bug.cgi?id=382

        Activity

        Hide
        Santiago Pericas-Geertsen added a comment -

        Will take a look at this one.

        Show
        Santiago Pericas-Geertsen added a comment - Will take a look at this one.
        Hide
        Santiago Pericas-Geertsen added a comment -

        I was able to reproduce the problem and found a workaround for it as well. The workaround: in CSW-
        discovery.xsd move the xs:include of 'report.xsd' after the xs:import's. Apparently, the schema loader is
        getting confused by the multiple imports of the same schema from different include paths (e.g. of
        owsCommon.xsd).

        Due to the large number of schemas and their intracte dependencies, it is very difficult to pinpoint the
        problem. I wonder if the original reporter of the JAXB issue could provide a simpler test case for us to
        work on.

        Show
        Santiago Pericas-Geertsen added a comment - I was able to reproduce the problem and found a workaround for it as well. The workaround: in CSW- discovery.xsd move the xs:include of 'report.xsd' after the xs:import's. Apparently, the schema loader is getting confused by the multiple imports of the same schema from different include paths (e.g. of owsCommon.xsd). Due to the large number of schemas and their intracte dependencies, it is very difficult to pinpoint the problem. I wonder if the original reporter of the JAXB issue could provide a simpler test case for us to work on.

          People

          • Assignee:
            jaxp-issues
            Reporter:
            kohsuke
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: