Creating Context-Dependent Data Models

Hi Folks,

Consider the problem of designing an XML Schema for a suitcase that has different content depending on the travel purpose. For example, if going on a vacation then the content of suitcase is shorts, Hawaiian shirts, and sunglasses; if going on a business trip then the content of suitcase is dress-shirt, tie, and jacket.

The suitcase has varying content. The suitcase is called a variable content container.

The XML Schema Best Practice for variable content containers describes four methods for creating variable content containers:

Use an abstract element and element substitution
Use a <choice> element
Use an abstract type and type substitution
Use a dangling type

http://www.xfront.com/VariableContentContainers.html

This message describes a fifth method. It uses a schema’s context to provide content for its variable content container.

Method 5: Implementing variable content containers using context schemas

The following XML Schema document -- vacation.xsd -- includes suitcase.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.trip.org/vacation"
           elementFormDefault="qualified">

    <xs:include schemaLocation="suitcase.xsd" />

    <xs:complexType name="clothes">
        <xs:sequence>
            <xs:element name="shorts" type="xs:string" />
            <xs:element name="Hawaiian-shirts" type="xs:string" />
            <xs:element name="sunglasses" type="xs:string" />
        </xs:sequence>
    </xs:complexType>

</xs:schema>

Here is a second schema document -- business-trip.xsd -- that also includes suitcase.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.trip.org/business-trip"
           elementFormDefault="qualified">

    <xs:include schemaLocation="suitcase.xsd" />

    <xs:complexType name="clothes">
        <xs:sequence>
            <xs:element name="dress-shirt" type="xs:string" />
            <xs:element name="tie" type="xs:string" />
            <xs:element name="jacket" type="xs:string" />
        </xs:sequence>
    </xs:complexType>

</xs:schema>

Both vacation.xsd and business-trip.xsd are context for suitcase.xsd. Both have a different namespace. Both define a complexType, clothes.

Now let’s examine suitcase.xsd. It is a no-namespace schema document. It declares a suitcase element and depends on context for filling in its content (for providing a definition of “clothes”):

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xs:element name="suitcase" type="clothes" />

</xs:schema>

If the context schema document is vacation.xsd then the content of suitcase is shorts, Hawaiian shirts, and sunglasses. If the context schema document is business-trip.xsd then the content of suitcase is dress-shirt, tie, and jacket.

Also notice that due to the Chameleon Effect the suitcase element is namespace-coerced to the namespaces http://www.trip.org/vacation and http://www.trip.org/business-trip, respectively.

This example illustrates a context-dependent data model -- the suitcase element depends on its context (environment) schemas to complete its content model.

Assessment

Method 5 is similar to method 4 (dangling types) but with one important difference: with method 4 the schema used to specify the content of the variable content container is specified in the XML instance document whereas with method 5 the schema used to specify the content of the variable content container is specified in the content schema. Thus, method 4 is a run-time association whereas method 5 is a compile-time association. That may be an important difference for your situation.

As with all engineering approaches, there are advantages and disadvantages. Let’s list them for method 5.

Advantages

- Dynamic: A schema which depends on its context is dynamic. It does not statically hard-code the identity of a schema item to implement the content. Rather, it empowers schema developers that use a context schema to identify content.

- Applicable to any Schema Item: The context schema is not limited to only complexTypes. It can provide elements, attributes, simpleTypes, complexTypes, in fact, any schema item. Thus, this method is useful for more than just variable content containers.

Disadvantages

- Context-Dependent Validation: A schema which depends on its context cannot be validated in isolation. It can only be validated in combination with its context schemas.

FAQ

Question: suitcase.xsd isn’t valid because type=”clothes” hasn’t been defined, right?

You are correct. When taken independent of context suitcase.xsd is invalid. Suitcase.xsd depends on a context schema for validity. Thus, don’t validate suitcase.xsd. Instead, validate vacation.xsd or business-trip.xsd.

This method turns things around 180 degrees from how one ordinarily thinks about XML Schema design. When designing schemas one doesn’t ordinarily think, “Oh, I’ll let the context (environment) schema documents provide the content here.”

While it does require a mental shift, I think method 5 may be capable of modeling the real world in a better way. After all, in the real world context plays a key role in most everything. Method 5 simply reflects that.

Questions for you:

1. Have you used the Method 5 approach? Did it work out well?

2. What other advantages and disadvantages do you see for Method 5?

/Roger