XML application development will take a big leap forward with the impending release of the XML Schema Description Language (XSDL) as a W3C Recommendation. XSDL goes far beyond what's offered today by DTDs with the addition of XML datatypes, namespace support, and inheritance mechanisms. However, features you require may not have made it into the language.

For this reason XSDL contains two methods for adding application-specific information directly to a schema. The first, the <appinfo> element, allows you to associate any structured content with most XSDL elements. The second is a lesser-known feature called foreign namespaced attributes (FNAs). These are attributes declared outside the XSDL namespace that can be placed within any XSDL element without affecting validation.

Why Extend XML Schema?
There are many reasons for extending an XML Schema. XSDL validates an XML instance document syntactically. While it provides some semantics through datatyping, it provides no semantic information about your data structures. For instance, you can say your <Quantity> tag is an integer and know that the information contained in the tag has certain properties defined by the XSDL integer datatype. However, although you can define the structure of an <Address> tag that contains a number of child elements, there's no way to describe what an address means. So adding more semantic information to a schema is one reason to create an extension.

Another area where extension mechanisms are useful is localization. XSDL was designed to promote data interchange. As such, the lexical space - how data is represented in text - is limited in its representation, meaning localized names and formats are severely restricted. By extending the schema, it's possible to provide an application that processes the data with localized versions of enumerations.

Mapping an XML Schema to another type of schema such as an RDBMS is another common use of these extension mechanisms. Getting data formatted in XML into and out of databases is a common programming task. Instead of writing code tied to a particular XML Schema to do the job, you can write code that both reads an annotated schema and can handle many different XML vocabularies. These are just a few of the many reasons why the XML Schema Working Group felt it was important to provide extension mechanisms in the language.

The <appinfo> Element
Listing 1 shows the XSDL definition of the appinfo element. This element and the documentation element are children of the annotation element, which can be used at the beginning of most major schema elements. The documentation element is meant for human-readable documentation. It's used here to point at the definition of appinfo in the XSDL specification (appinfo is different from documentation in that it's meant for tools or applications).

Both appinfo and documentation define a single attribute called source that can appear on the element. This attribute has a type of anyURI, so any valid URL can appear there. XSDL doesn't define what action should be taken if the source attribute is present; that's left up to the application processing the schema. appinfo also supports mixed content; that means that both character and element data can appear as part of an appinfo element. Finally, note the <any> element that is part of the complex type definition of appinfo. This is known as a wildcard in XSDL, and is used to support Open Content Models. It allows any element content from any XML namespace to appear as a child on appinfo. The processContents attribute informs the schema processor how that content should be validated. (I'll cover this in more detail later.)

Let's use appinfo to create an extension. As mentioned above, you can use appinfo to provide localized names for enumerations. Listing 2 contains a schema fragment that defines an enumerated type, TextNumbers, that allows the values "one," "two," and "three." For an attribute or an element that has the type TextNumbers to be schema-valid, it must contain one of these three values. However, this isn't very I18N-friendly. We want to use appinfo to provide localized versions of this enumeration.

The first thing to do is declare a namespace for our extension. This is very important because it'll have validation errors if it's not outside the XSDL namespace. In Listing 3 you can see this namespace declared in the schema element. Next, we need to define how the markup will look. I decided to create a localized element that uses the attribute xml:lang to specify the language of the enumeration. This element will have three child elements called enumeration that contain a value attribute that has the localized enumeration name. For the English language I'll use an attribute named default to signify that the values in the actual enumeration should be used.

Any application that supports our extension can now parse the schema and display localized values for this particular enumeration. Applications that don't support our extension will ignore the appinfo and display the enumeration in English. It's important to note that although an application may display a localized enumeration, for an XML instance to be valid it must use the real values defined in the enumeration. You'll get an error if you try to use the value "uno" instead of "one" when you validate an XML instance.

<appinfo> in Use
Now let's look at an example of appinfo that's in use today. The XML Schema Working Group has taken advantage of this element to align the specification with the Schema for Schemas. Listing 4 shows a fragment for the Datatypes Schema that defines the String simple type.

All the simple types defined in the Datatypes Schema use an appinfo extension to specify what properties and facets a particular datatype supports. The specification itself is in XML and uses an XSLT stylesheet to create the HTML displayed in the browser. This stylesheet reads the hasFacet and hasProperty elements inside each type and displays them inside the specification. By doing this, there is less chance of an error cropping up because the schema didn't agree with the specification.

The XML Schema Working Group has also created a schema for this particular appinfo extension. A fragment of that schema is shown in Listing 5. The interesting thing to note is that the semantics for using this extension are contained within the documentation tag. As I noted earlier, the XSDL specification defines no semantics for the use of appinfo. One question that may come up for this particular extension is how to determine which facets and properties a user-defined datatype has. This answer is contained in the documentation element (Listing 5), which states:

A schema processor (or the XSLT which generates the HTML version of the XML Schema Part 2: Datatypes specification) which reads a derived simpleType definition should walk up the base type chain until it reaches the primitive type at the top of the chain and "push" all facets found there down to all derived types in the chain.

By providing a documented schema for your appinfo extension, you not only provide users with the means to validate their use of the extension, but you can also add rules on how the extension should be used. If you want to provide a tool that displays all the facets and properties of all the datatypes used in a particular schema, you know what you need to do for those derived types that don't have their own appinfo element.

Foreign Namespaced Attributes
As mentioned earlier, the second extension mechanism available to schema authors is FNAs. These are attributes that are defined in a namespace outside the XSDL namespace and applied directly to schema elements. Like appinfo, they have no effect on schema validation, and a processor not designed to use the extension will just ignore them.

You use FNAs much like you use appinfo. First you add a namespace declaration to the schema your attributes will be in. Now you're free to add these attributes throughout your schema.

FNAs in Use
Foreign namespaced attributes are well suited to adding metadata to your schema as opposed to structured content. For instance, mapping database field names to attribute and element declarations is a perfect use for FNAs. It simplifies parsing of the schema as well as making it easier for someone reading the schema to see the association.

Progress Software uses FNA to support B2B e-commerce within the Progress product line. Progress needed a way to take an XML message received by SonicMQ, a JMS-based e-business messaging server, and get it into our application partners' business applications without requiring them to rewrite their business logic; we accomplished this by creating a schema-mapping technology that allows XML data to be consumed or generated by an existing application with minimal need for new code.

Figure 1 shows the Progress schema mapping tool. The left pane shows a tree that represents an XML Schema that was loaded in the tool. The right pane has what Progress calls Smart Business Objects or Smart Data Objects that contain your program's business logic. Using the tool, you map your XML instance data as defined by an XML Schema to either column of an SDO or to methods of an SBO. When this is completed, you're left with an annotated schema. An example of this schema is shown in Listing 6. The attributes with the prgs: prefix contain the metadata that lets Progress know what to do. If you're consuming XML, new SDOs and SBOs are created and populated with the XML instance data. If you're producing XML, existing Smart Objects are used to generate XML. These XML messages are then processed by SonicMQ to make sure they get where they're supposed to go.

Validating Schema Extensions
Now that you've created a schema extension, it makes sense to utilize the power of XSDL to validate the use of these extensions. XSDL provides three modes of wildcard validation. As noted earlier, wildcards are what you use in XSDL to specify that any content can appear in a certain place, and the processContents attribute specifies the validation mode to use. When processContents is set to "strict", a schema is required for any content that appears in place of a wildcard. If an element or attribute doesn't have a corresponding type definition, a validation error will be thrown.

On the opposite end of "strict" is "skip". When processContents is set to "skip", no validation will occur even if there is schema information. Finally, we have the middle ground of "lax". If you remember the example in Listing 1, processContents was set to "lax" for the appinfo element. This means that if you have schema information for the content appearing in appinfo, use it to validate; if you don't, don't worry about it. This is how an application that cares about a particular extension can validate its use, while an application that doesn't know about it will still validate the XML instance even if the extension is used incorrectly.

The Schema Adjunct Framework
Now that we know the mechanisms that the XSDL provides for creating extensions, there is the question of their effects on interoperability. Some members of the XML community consider appinfo and FNAs harmful. I don't believe they harm interoperability because applications that don't care about extensions will still be able to process the XML instance as they would an instance not using an extension. However, there is a need to make it easy to create and use schema extensions and that is where the Schema Adjunct Framework (SAF) comes in.

SAF was originally developed by Tibco Extensibility to provide a way to create extensions that could be used in an interoperable manner. Software AG, Progress Software, and others are refining it with hopes of submitting it to the W3C for standardization. SAF defines a framework for creating schema adjuncts. These adjuncts can be used to extend DTDs and other schema languages besides XSDL.

The idea is that by creating this framework, developers won't have to write a lot of schema-specific code for processing an instance. This is referred to as schema lock-in. By allowing application- or domain-specific data to be associated with document nodes or schema definitions, there is less need to write code for every different document type you need to understand, as we saw with the Progress SmartB2B example. The current SAF specification talks mostly about a separate "adjunct" XML document that contains this information. You may choose to use separate adjunct files when you need to create multiple extensions for the same schema, or you do not "own" the schema and annotation isn't possible. However, the process of creating adjuncts using appinfo and FNAs is similar, and the specification is being beefed up in that regard.

For More Information . . .
XSDL is currently a Proposed Recommendation by the W3C. This is the final step in the standardization process, and it means that the specification is stable, barring unforeseen circumstances. You can find it at www.w3.org/XML/Schema. For more information on Progress SmartB2B objects, go to www.progress.com. For more information on SonicMQ, go to www.sonicmq.com. Information on the SAF can be found at www.extensibility.com/tibco/resources/saf.htm. Finally, you can download two presentations that I've given on this topic. The first - the basis for this article - can be found at www.freeframework.org/downloads/xml/schemaext.zip. The second, "4th Generation XML Application Development," discusses the ideas created behind Progress's schema mapping tool and can be found at www.freeframework.org/downloads/xml/4thgenxml.zip.

The appinfo element and FNAs offer a lot of power in the use of XSDL. If you feel any features are missing in XSDL, you can add them yourself through these mechanisms. Who knows? They may be added to a future version of the XML Schema Specification.

• Figure 1
• Source Code