Creating Extensible Content Models XML Schemas: Best Practices A set of guidelines for designing XML Schemas Created by discussions on xml-dev

Definition An element has an extensible content model if in instance documents that element can contain elements and data above and beyond what was specified by the schema.

Static, Fixed Content Model The First and Last Freedom J. Krishnamurti Harper & Row Book is rigidly defined to contain five child elements - Title, Author, Date, ISBN, and Publisher. Instance document authors are restricted to just supplying title, author, date, ISBN, and publisher data for a book. Book's content model is static/fixed!

Static, Fixed Content Model Sometimes it is desirable to explicitly specify an element's content model. Sometimes, however, we want to give instance document authors more flexibility in what data they can provide for an element. How do we design a schema such that Book's content model is extensible? We will look at two methods for implementing extensible content models.

Extensibility via Type Substitution

-- content -- Principle of Type Substitutability The content model of Book can be either BookType, or any type which derives from BookType, e.g., BookTypePlusReviewer Extensibility via Type Substitution

The First and Last Freedom J. Krishnamurti Harper & Row Roger L. Costello The type substitutability mechanism enables instance document authors to extend Book's content model by substituting its type with a derived type. Here we see that BookType has been substituted by the type: BookTypePlusReviewer. Thus, now contains a new element,. Extensibility via Type Substitution Do Lab1

Extend a Schema, without Touching it! In the last example BookTypePlusReviewer derived from BookType, and both types were in the same schema. What if we need to extend BookType, but BookCatalogue.xsd is read-only? In a separate schema, we can create a type which extends BookType. The instance document can do type substitution using the new type. Thus, we are able to extend a schema, without touching it!

Extend a Schema, without Touching it! BookCatalogue.xsd xmlns=" MyTypeDefinitions.xsd

Extend a Schema, without Touching it! The First and Last Freedom J. Krishnamurti Harper & Row Roger L. Costello xsi:schemaLocation=" MyTypeDefinitions.xsd" xmlns=" We have type-substituted Book's content with the type specified in the new schema. Thus, we have extended BookCatalogue.xsd without touching it!

Disadvantages of using Type Substitution for Extending an Element's Content Model Location Restricted Extensibility: –The extensibility is restricted to appending elements onto the end of the content model (after the element). What if we wanted to extend by adding elements to the beginning (before ), or in the middle, etc? We can't do it with this mechanism.

Disadvantages of using Type Substitution for Extending an Element's Content Model Unexpected Extensibility: Simply looking at these components you would think that will always contain just Title, Author, Date, ISBN, and Publisher. It is easy to forget that someone could extend the content model using the type substitution mechanism. Extensibility is unexpected! Consequently, if you create a program to process Book's content you may forget to take into account that Book may contain different content.

Here's what we Desire for Extending Content Models Location Independent Extensibility: –We would like to be able to extend Book's content at any location, not just at the end. For example, we might wish to add elements at the top (before Author), or in the middle (after Date), etc. Explicit Indication of where Extensibility may Occur: –It would be nice if there was a way to explicitly flag places where extensibility may occur: "hey, instance documents may extend at this point, so be sure to write your code taking this possibility into account."

Extensibility via the Element "The content of Book is Title, Author, Date, ISBN, Publisher and then (optionally) any well-formed element. The new element may come from any namespace." Note: the element may be inserted at any point, e.g, it could be inserted at the top, in the middle, etc.

Extensibility via the Element xmlns=" MyRepository.xsd xmlns=" BookCatalogue.xsd In an instance document I can insert this Reviewer element after Publisher.

The First and Last Freedom J. Krishnamurti Harper & Row Roger Costello xsi:schemaLocation=" BookCatalogue.xsd MyRepository.xsd" xmlns=" xmlns:rev=" This instance document author has extended Book with an element that the schema designer may have never even envisioned. We have empowered the author to create instance documents which contains all the data he/she requires.

Alternate Schema for Book This is a better design than the previous version since now we have a nice reusable BookType component. However, we are back to the "unexpected extensibility" problem. Consequently, after the Publisher element there may be any well-formed XML element, and after that anything could be present (due to type substitutability).

Controlling Extensibility using the block Attribute We can add a block attribute to the element declaration to prohibit type substitution:

Control over where and how much Extensibility We can put the element specifically where we desire extensibility. If we desire extensibility at multiple locations, we can insert multiple elements. With maxOccurs we can specify "how much" extensibility we will allow. - We are restricting extensions to occur at the top of the content model. - We are restricting the amount of extensibility to two elements.

Recognizing our Limitations The element allows a schema designer to recognize that he/she is not able to anticipate all the varieties of data that an instance document author might need to use in creating an instance document: "I'm smart enough to know that I'm not smart enough to anticipate all possible needs!" Do Lab 2

Non-determinism and the element My Life and Times... Schema: Instance: Does this element correspond to the element, or the Title element declaration? Impossible to determine without "looking ahead" to the next element. The Book element has a non-deterministic content model. Non-determinism content models are illegal.

Definition of Non-determinism Defn: A non-deterministic content model is one where, upon encountering an element in an instance document, it is ambiguous which path was taken in the schema document.

Non-determinism and the element My Life and Times... Schema: Instance: Clearly this element must have come from the Title element declaration, because the element requires new elements to come from a namespace other than the targetNamespace. Thus, this schema has a deterministic content model and is legal.

Non-determinism and the element My Life and Times... Schema: Instance: Does this Title element come from the element, or from the Title element being ref'ed? There is no way of knowing, without looking ahead. Thus, this is non-deterministic, and illegal. Suppose that the Book element is comprised of components from a variety of namespaces.

--> Quite Restricted As we have seen, the requirement that all elements have deterministic content models imposes serious restrictions on the use of the element. So, what do you do when you want to enable extensibility at arbitrary locations? Answer: embed the element within an element.

My Life and Times... Schema: Instance: Now we are forcing any additional elements to be embedded within an optional element. No more ambiguity about where this Title element comes from, i.e., no more non-determinism! Embed Additional Elements within an Element

Commentary Requiring instance document authors to nest additional element within an element is poor, at best. The whole reason that this design pattern was forced upon us is due to XML Schemas rule outlawing non- deterministic content models. –They did this to simplify implementations of Schema validators. Write to the XML Schema Working Group requesting that they remove the rule outlawing non-deterministic content models.