Fixed default namespace not working correctly #87
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From my understanding, the code does not handle cases correctly where there are default namespaces supposed to be used by an xsd file. Rather, the code assumes the default namespace to be the targetNamespace, which is incorrect. This bugfix fixes the behavior to work as intended by W3C XML Schema.
Two other bugs were fixed along the way:
Consider this example:
The default namespace is defined as http://www.w3.org/2001/XMLSchema. Thus, every child element of schema (the attribute element as well as the type int) belongs to this namespace. The code, however, assumes during its validation process that the type int belongs to the targetNamespace http://www.example.com/ and looks for its definition there, where it is obviously not going to find it since this namespace only defines the attribute myCustomAttribute and nothing else. So the code throws an error.
With the bugfix applied, the code assumes the correct default namespace of http://www.w3.org/2001/XMLSchema to be the one in which to look for the definition of type int for, thus not throwing an error.
There is an edge case here where no default namespace could be defined in the schema above, and it could still be valid XSD. The type int would be in no namespace. The code, however, throws an error without further validation. To validate this edge case correctly, the code would have to look for the definition of type int in the imported schemas that define 'no namespace' components, which are indicated by the 'noNamespaceSchemaLocation' attribute in the http://www.w3.org/2001/XMLSchema-instance namespace. This edge case would require some more refactoring within the namespace handling and is therefore ignored within this bugfix. I will probably look into it later on.
The tests also had to be adapted to match the new logic. In general, I added the xmlns:ex=http://www.example.com/ attribute to the schema element to define the 'ex' prefix for the namespace http://www.example.com/, which was the targetNamespace for all the tests that needed changing. I then also had to reference the components defined in the schemas by prefixing them with the 'ex' prefix since I did not provide a default namespace, and otherwise we would be in the edge case above. Lastly, I added 2 new tests to check if the default namespace is used correctly and that an unknown namespace to the schema fails the validation.
For further information, https://www.oracle.com/technical-resources/articles/srivastava-namespaces.html explains very well how default namespace and targetNamespace work within XSD.