Including a schema without namespace into a schema with namespace is not possible

• Key: WSCOMMONS-78
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Jochen Wiedmann
• Component/s: XmlSchema

Description

The XML Schema specification states in "4.2.1 Assembling a schema for a single target namespace from multiple schema definition documents":

  2 One of the following must be true:
  ...
  2.3 SII has no targetNamespace [attribute] (but SII' does).
  3 The appropriate case among the following must be true:
  ...
  3.2 If clause 2.3 above is satisfied, then the schema corresponding to the <include>d item's parent <schema> must include not only definitions
  or declarations corresponding to the appropriate members of its own [children], but also components identical to all the - schema components- of I,
  except that anywhere the - absent- target namespace name would have appeared, the - actual value- of the targetNamespace [attribute] of SII' is used.
  In particular, it replaces - absent- in the following places:
  3.2.1 The {target namespace} of named schema components, both at the top level and (in the case of nested type definitions and nested attribute and
  element declarations whose code was qualified) nested within definitions;
  3.2.2 The {namespace constraint} of a wildcard, whether negated or not;

In other words, it is possible to include a schema without namespace, as if it had the namespace of the including schema.

Unfortunately this fails with XmlSchema, as the attached patch demonstrates. The patch includes a simple test case and could be applied, if this bug is fixed.

Suggested resolution, as realized in JaxMeXS: If such a schema is being parsed, then mutable instances of QName should be created, which would always
return the target namespace of the schema.

Comments

[Jochen Wiedmann]

The attached patch is based on the patch, which is provided in WSCOMMONS-81.

Note, that the patch introduces some incompatible API changes. However, these changes are caused by design errors in the API. For example, it is invalid to assume, that a schema with a given system ID can be included only once. Likewise, it is invalid to assume that only one schema with a given target namespace exists.

[Davanum Srinivas]

I tried cleaning up...no luck :(

patching file src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java
Hunk #1 FAILED at 27.
Hunk #2 succeeded at 41 (offset -3 lines).
Hunk #3 succeeded at 75 with fuzz 1 (offset -3 lines).
Hunk #4 succeeded at 225 (offset -3 lines).
Hunk #5 FAILED at 273.
Hunk #6 FAILED at 500.
Hunk #7 succeeded at 1309 (offset 108 lines).
Hunk #8 succeeded at 1330 (offset 108 lines).
Hunk #9 succeeded at 1508 (offset 140 lines).
Hunk #10 succeeded at 1811 (offset 240 lines).
Hunk #11 succeeded at 1858 (offset 240 lines).
Hunk #12 FAILED at 1880.
Hunk #13 succeeded at 2084 (offset 241 lines).
Hunk #14 succeeded at 2151 (offset 256 lines).
4 out of 14 hunks FAILED -- saving rejects to file src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java.rej
patching file src/main/java/org/apache/ws/commons/schema/utils/TargetNamespaceValidator.java
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaException.java
patching file src/main/java/org/apache/ws/commons/schema/XmlSchema.java
Reversed (or previously applied) patch detected! Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
5 out of 5 hunks ignored -- saving rejects to file src/main/java/org/apache/ws/commons/schema/XmlSchema.java.rej
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaSerializer.java
Hunk #1 succeeded at 93 (offset -4 lines).
patching file src/main/java/org/apache/ws/commons/schema/XmlSchemaType.java
patching file src/test/java/tests/CircularSchemaTest.java
patching file src/test/java/tests/IncludeTest.java
Hunk #2 FAILED at 120.
Hunk #3 FAILED at 127.
2 out of 3 hunks FAILED -- saving rejects to file src/test/java/tests/IncludeTest.java.rej
patching file src/test/test-resources/includedWithoutNamespace.xsd
patching file src/test/test-resources/includingWithNamespace.xsd

[Jochen Wiedmann]

Did you apply the patch for WSCOMMONS-81 in advance? In either case, we should resolve that one first.

[Davanum Srinivas]

I've applied WSCOMMONS-81, Can you please sync up with latest SVN and submit a new patch for this bug report.

thanks,
dims

[Jochen Wiedmann]

In the meantime, I have detected that Axis 2 depends much, much more on these deprecated API's than I had expected. Unfortunately that means, that the serialization stuff in Axis 2 is most likely broken, at least if it depends on the same assumptions, which are implicit in the API. (Basically, it is assumed that all namespaces are declared in the top level elements, which is of course recommendable, but cannot be trusted.)

I'll try to understand the serialization framework in Axis 2 first, before I'll continue my work.

[Davanum Srinivas]

Jochen,

I can run more tests to check but i'd prefer that we stick to the game plan and get the changes for 78 in (which may break more things) and then i can clean up afterwards in time for Axis2 1.1 release.

thanks,
-- dims

[Jochen Wiedmann]

Ok, Dims, as requested, here's the updated patch.

[Davanum Srinivas]

Applied as-is. looks good.

thanks,
dims

Hi, I am sorry to report that I created a duplicate log,
http://issues.apache.org/jira/browse/WSCOMMONS-87
But please, have a look anyway at the included test case which could be added to the test suite.
Thank you.