[JAXP-44] If multiple schemas contain same targetnamespace, only the first one is used in schema validation Created: 09/Oct/07  Updated: 19/Oct/07

Status: Open
Project: jaxp
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Improvement Priority: Major
Reporter: jitu Assignee: jaxp-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File test.zip    
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.



 Comments   
Comment by jitu [ 10/Oct/07 ]

Created an attachment (id=13)
test case

Comment by Santiago Pericas-Geertsen [ 18/Oct/07 ]

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.

Comment by jitu [ 18/Oct/07 ]

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.

Comment by kohsuke [ 18/Oct/07 ]

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.

Comment by Santiago Pericas-Geertsen [ 19/Oct/07 ]

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.

Generated at Mon Jan 16 17:31:58 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.