Accepting Foreign Namespaces

The previous couple of schemas can validate instance documents independently of the prefixes being used. They meet the first goal of namespaces: disambiguating elements in multinamespace documents. However, they will fail to validate the instance document where we’ve added the dc:publisher element. You can easily update the schema to explicitly add this element to the content model of our book element, but that won’t make it an open schema that accepts the addition of elements from any other namespace.

Instead of some magic feature that could have been quite rigid, RELAX NG introduced a flexible and clever feature that lets you define your own level of “openness.” The idea is to let you define your own wildcard, and, once you have it, you can include it wherever you want in your content model.

Constructing a Wildcard

Before we start, I’ll define what we are trying to achieve! We want a named pattern allowing any element or attribute that doesn’t belong to our lib or hr namespaces. We probably want to exclude attributes and elements with no namespaces; attributes, because our own attributes have no namespace, and we might want to differentiate them; and elements, because allowing elements without namespaces in a document using namespaces violates the general intent of disambiguating content. The content model of the elements we’ll accept can be anything.

Let’s start by defining the inner content of the wildcard and define what we want our “anything” to be. ...

Get RELAX NG now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.