The Case for Open Schemas

It’s good to design extensible schemas, but they make an impact only on developers who can extend our initial schema. A document valid per an extended flavor of our schema is likely to be invalid per our original schema.

By contrast, an open schema lets instances be extensible and allows the addition of content while still remaining valid against the original schema. Of course because the additions are unpredictable, the validation of their structure will be very lax, but extended documents will still be considered valid.

Designing and using open schemas is quite challenging because it gives more power to the XML user, and unexpected situations may result. The use of open schemas also conflicts with some best practices of schema usage: a totally open schema validates any well-formed XML document and is thus totally useless. On the other hand, closed schemas violate the fundamental principle of extensibility of XML, the extensible markup language.

There are several levels of openess from a totally closed schema in which nothing unexpected can happen, to the most extreme case, which allows any well-formed document. In RELAX NG, name classes (introduced in Chapter 10) are the basic blocks that will let you build the wildcards needed to open a schema We’ll take a closer look at name classes before presenting the constructions most often used in open schemas.

More Name Classes

Here I’ll first recap the name classes seen in the previous chapter. You’ve seen how to ...

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.