Geek Answers Handbook

Round XSD Import

I need to XSOM XSD using XSOM , but this XSD contains loop import.

A.xsd

 <xs:schema xmlns="ns1" targetNamespace="ns1"> <xs:import namespace="ns2" schemaLocation="B.xsd"/> <xs:element name="MyElement" type="xs:string"/> </xs:schema>

B.xsd

 <xs:schema xmlns="ns2" targetNamespace="ns2" xmlns:ns1="ns1"> <xs:import namespace="ns1" schemaLocation="A.xsd"/> <xs:complexType name="MyComplex"> <xs:sequence> <xs:element ref="ns1:MyElement" minOccurs="0"/> <xs:sequence> <xs:complexType> </xs:schema>

XSOM Unable to parse a schema because it detects elements that are already defined due to circular import. So I tried to break down the circular import by displacing the elements defined by A and used in B.

C.xsd contains an element from A that is used by B. Note that these elements are not used in A. Do not ask me why they were defined in A.

 <xs:schema xmlns="ns1" targetNamespace="ns1"> <xs:element name="MyElement" type="xs:string"/> </xs:schema>

A.xsd becomes

 <xs:schema xmlns="ns1" targetNamespace="ns1"> <xs:import namespace="ns2" schemaLocation="B.xsd"/> </xs:schema>

B.xsd (import C.xsd instead of A.xsd) becomes

 <xs:schema xmlns="ns2" targetNamespace="ns2" xmlns:ns1="ns1"> <xs:import namespace="ns1" schemaLocation="C.xsd"/> <xs:complexType name="MyComplex"> <xs:sequence> <xs:element ref="ns1:MyElement" minOccurs="0"/> <xs:sequence> <xs:complexType> </xs:schema>

XSOM can parse XSD. But now I can not create a circuit with the following code:

 SchemaFactory sf = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); sf.setResourceResolver(new MyResourceResolver());

I use the standard implementation bundled with JDK 1.7. I get an exception:

 src-resolve: Cannot resolve the name 'ns1:MyElement' to a(n) 'element declaration' component.

The problem is that the resource recognizer is called for namespace B, but not for namespace A, which makes sense. Because the namespace A is shared between A.xsd and C.xsd, the resource recognizer cannot find the elements defined in C.xsd.

Are circular imports valid? Is it possible to split circular imports so that it can be analyzed using XSOM and then loaded using SchemaFactory ?

+4
source share
1 answer

On a general issue:

You ask: "Are circular imports valid?" If by roundness you mean that there is a chain of documents of the scheme S [1], S [2], ..., S [n], where the document of the scheme S [1] refers to the document of the scheme S [2] by name, S [2] - S [3], ... S [n-1] - S [n] and S [n] - S [1], then I do not believe that the specification XSD 1.0 or XSD 1.1 speak clearly or other. (Some WG members tried to convince the WGs to improve the clarity of their thinking on these and related topics, but failed.) Some implementations support circular import (and other forms of roundness), but I don’t think it can be argued from the specification that your implementation does what something wrong.

If, on the other hand, you only mean that there exists a cycle such that for 0 <= i <= n-1, S [i] imports the namespace S [i + 1] and S [n] imports the space names S [1], then I believe that such cycles are clearly legal (and in some cases inevitable).

The workaround that I recommend is:

  • In any schema document that states something, use xs: import as needed, but do not specify the location of the schema when importing. The loops in such links are harmless.
  • When calling the schema processor, give it a complete list of all the schema documents that you want to read, and if possible, inform it through the parameters or configuration so as not to read any other schema documents.
  • If your schema document does not accept multiple schema documents as input during validation, so you should have one schema document that references everything you want to read, or if you do not trust yourself to get a list of schema documents directly in call time, then add a top-level driver document that does nothing but enable and import other schema documents that you want to read, with specific information about the location of the schema.

In your case, this would mean removing the xs: import / @ schemaLocation attribute from (source forms) A.xsd and B.xsd and adding a form driver document

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="ns1" schemaLocation="A.xsd"/> <xs:import namespace="ns2" schemaLocation="B.xsd"/> </xs:schema>

The effect is to ensure that there are no cycles of links to documents of the schematic documents to other documents of the scheme; which eliminates a very large class of cases where XSD implementations are incompatible with each other (and in some cases with itself - sometimes the same processor produces significantly different results on the same inputs when the call calls the inputs in a different order).

On a specific issue:

In your example, there is no requirement that ns2 be imported either A.xsd or C.xsd, because none of them contain references to any components in the ns2 namespace. So the loop in your example seems to be free.

In your second example, you give some code that the circuit cannot load. But I do not see references to this code on any particular schema document at all; unless there is something meaningful that you are not showing us, it is not surprising that the validator cannot find an ad for {ns1} MyElement.

+5
source

More articles:


All Articles