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.