Skip to main content

skip to main content

developerWorks  >  XML  >

Compound XML document profiles for rich content, Part 2: A pattern for developing compound XML document schemas

developerWorks
Document options

Document options requiring JavaScript are not displayed


New site feature

Check out our new article design and features. Tell us what you think.


Rate this page

Help us improve this content


Level: Advanced

Steve Speicher (sspeiche@us.ibm.com), Senior Software Engineer, IBM
Kevin E. Kelly (kekelly@us.ibm.com), Senior Software Engineer, IBM

21 Sep 2005

Build compound XML Schema profiles from core specification schemas. Part 1 of this two-part series explores several extension capabilities of XML Schema and compares approaches in building Compound Document Format (CDF) profiles. This article defines a pattern for developing mixed-namespace profiles using XML Schema, based on the analysis in Part 1.

Overview

User demand for rich Web application content is continually increasing for both desktop and mobile device platforms. Open, standards-based functional XML schemas enabling rich content help ensure that such content -- and the skills required to produce it -- remains ubiquitous, accessible, and cost effective. Schemas also help ensure that this technology does not become a proprietary format for a single or small number of vendors constrained to specific programming frameworks or to specific renderer and browser technologies.

XML-based, declarative functional schemas like XHTML, XForms, XML Events, Scalable Vector Graphics (SVG), SMIL, VoiceXML, and XHTML Mobile Profile are examples of schemas that provide specific functionality for creating rich content.

Each functional schema pertains to a specific area of functionality. For example, SVG addresses graphics; XForms addresses form input collection and submission; XML Events addresses the creation of events and listeners; and so on. However, most rich Web applications require a combination of two or more of these functional schemas within a single document. Combining schemas can be problematic because not all schemas can be embedded within other schemas. And not all schemas allow other schemas to be embedded within themselves. In fact, most functional schemas assume that they are the root schema in a single document with only one functional namespace and that if the need arises for rich content from another functional namespace, a separate document can be referenced with its own root schema. For example, an XHTML document can reference an SVG graphic in a separate document at runtime to render the graphic.

Some schemas are written specifically to be embedded, such as XForms (which was never intended to be the root schema in a document). Other schemas have been adapted for embedding through the use of newer schemas that forge a combination of existing functional schemas (such as XHTML and VoiceXML's X+V profile). The XForms specification includes guidance for enclosing schemas, but an actual combining driver schema does not exist. In the case of X+V, a separate driver schema was created by copying the VoiceXML schema and replacing specific elements with XHTML schema elements.

There isn't much clear guidance for user agent developers or content creators about which tags from XForms are allowed under XHTML tags or which XHTML tags are then allowed under XForms tags.


Figure 1. Sample rendered compound document using XHTML, MathML, and SVG
Sidewinder screenshot


Back to top


Defining profile schemas

A key element of this pattern is the use of a profile schema that provides the redefinitions that enable the creation, modification, and validation of compound XML documents. Using this approach, you can separate the desired combination of valid cross-namespace element combinations without violating the integrity of the core functional schemas. As an example of this, Part 1 outlines a simple compounding that enables XForms elements within an XHTML document, and likewise enables XHTML elements within XForms elements, as shown in Figure 2.


Figure 2. Sample of pattern for defining CDF profile schemas
Sample of pattern for defining CDF profile schemas

As you learned in Part 1, using XML Schema redefines gives you the flexibility you need to extend the core schemas.

You need at least one profile schema for each combination of namespaces. However, in some cases you may be able to create a single profile schema to redefine one schema while introducing more than one foreign namespace. We recommend using modularization and separating these redefinitions, because they may be useful independently or with other combinations.

Keep in mind that you can reuse these profile schemas to create bidirectional combinations or combinations with other namespaces.



Back to top


Enabling core schemas for redefines

In the following subsections, we highlight recommendations for developing core schemas using redefines. These recommendations allow your core schemas to be easily redefined without being modified -- or, at least, help keep modifications to a minimum.

Using anonymous types (Don't!)

It's impossible to use an XML Schema redefine on a simple or complex declaration if it's done anonymously (within the context of the actual element/attribute declaration). Instead, you should expose these types by defining the content of the elements and let the element declaration reference the type.

This approach also enables better internal componentization and abstraction: You can define abstract and reusable parent types, and you can also make new extensions and restrictions.

Grouping items appropriately

When using redefine (and for good schema design in general), it is often desirable to define content models based on global group definitions. When you define element and attribute content using groups, you can easily extend the existing group definition to include additional items.

Defining global elements

When declaring an element outside the context of a type declaration or group, you need to be careful because the scope is global. This step also has the effect of enabling the element to be a valid root element in an instance document. This can misdirect generation tools to create documents with unintended root elements, at least from the point of view of the schema author. However, schema validation tools using the schema do not report a violation. So use global element declarations sparingly.

The use of global elements can prove useful, however, when elements from different namespaces are referenced within the complex content definition. This is the case in the example in Part 1, in which the global XHTML p element is added to the extended complex type definition for the XForms select element. Even so, the ideal solution is to reference a group declaration from the XHTML schema that includes a declaration of the p element.

Understanding naming conventions

Naming conventions, which exist for all types of programming languages, enable readers to quickly understand additional metadata about a language construct. Without such conventions, the reader must either research the language construct or depend on the tooling to provide visual indicators. These conventions can be quite useful in helping users understand differing core schema constructs. A recommended convention is one used in the XHTML modularization effort. (See Resources.)

Modularizing whenever possible

Although not a key aspect of this pattern, modularization can provide key benefits for the reuse, understanding, extensibility, and maintenance of schemas. For compound documents, modularization eases the construction of new schemas by providing a driver schema that includes and imports the appropriate modules. This driver schema can either be modified or redefined using the techniques explained in this article and in Part 1.



Back to top


Looking at XHTML and XForms

As we mentioned in Part 1, the intent of this series is to explore high-level scenarios and design patterns for building robust and reusable schemas that define a solid validation framework for compound document content. The details on valid content and semantics are being codeveloped by the W3C's XHTML 2.0, XForms, and CDF Workings Groups. (See Resources.)



Back to top


Summary

Following the pattern defined in this article, both standards designers and business data modelers can benefit from more reusable document and data models. They can also benefit from having a technique (pattern) for embedding other data models (schemas) and for being embedded by other data models. Designers often think that their root element will always be the root, but then later realize there are many valuable scenarios where their model needs to exist within other models.



Resources

Learn

Get products and technologies

Discuss


About the authors

Steve Speicher is a Senior Software Engineer with IBM working on Software Standards. Steve's current focus is leveraging tools and model-driven development to improve the process of creating standards. Steve has previously worked on software development tools in the Rational division and IBM internal tools. Steve holds a B.S. in Computer Science and Applied Mathematics, both from Kent State University. Contact Steve at sspeiche@us.ibm.com.


Kevin E. Kelly is a Senior Software Engineer with IBM working on software standards. Kevin is a member of the W3C XForms Working Group and the Chair for the W3C Compound Document Format Working Group. His focus is on the client technology and evolving open standards-based technologies for faster, more efficient standards adoption through XML-based and model-driven approaches. Before joining IBM, Kevin spent eight years at Rational software working on UML modeling and Java technologies. Kevin holds a B.S. from Mercer University and a M.S. from the University of Montana. Contact Kevin at kekelly@us.ibm.com.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful
Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top