Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed default namespace not working correctly #87

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

marckoehler
Copy link

@marckoehler marckoehler commented Nov 18, 2024

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:

  • The implicit anyType for an element - if the namespace http://www.w3.org/2001/XMLSchema was the default namespace - would be passed as ':anyType' instead of just 'anyType' which led to wrong behavior later on.
  • If an element used a namespace prefix and that namespace could not be found in the schema, the code just assumed that the element's namespace was the target namespace, which was incorrect. In this case, an error will now be thrown.

Consider this example:

<schema targetNamespace="http://www.example.com" xmlns="http://www.w3.org/2001/XMLSchema">
    <attribute name="myCustomAttribute" type="int"/>
</schema>

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant