lthough XML Schema was intended to be used to provide a better validation and definition layer for XML than Document Type Definitions (DTDs), certain underlying concepts were translated unintentionally. One concept was the notion that attributes could be set to enumerations (lists), but those enumerations needed to be specified within the schema itself. As XML becomes more distributed, as data structures become more complex and dependent on not just static but dynamic definitions, developers are beginning to recognize the need to have a schema language that itself supports such dynamic definitions.

Because ISO Schematron can now utilize XPath 2.0 (especially including functions such as doc() and unparsed-text()), Schematron may prove to be the critical "distributed validation" language for business content. I'll discuss Schematron in more detail later, but many issues for which Schematron seems remarkably well suited became obvious to me while doing some consultative programming for Nordstrom—the high-end clothing retailer.

I was developing a method—through deployment over the web—to validate, display, and edit invoices coming from its vendors. At that time the EDI standard was being phased out for some form of XML (ebXML was still a year out from being finalized). Being of an XMLish sort of mind, I pulled out the tools that were available to me, including the newly minted XML Schema, and began modeling the invoices in XML Schema Definition (XSD). Most invoices mapped fairly cleanly. Where things got a little bit more problematic was having to validate to ensure that a given store ID was correct.

This problem may seem easy, perhaps even obvious, to solve: merely enumerate the list of stores in the schema <xs:enumeration> elements, right? However, Nordstrom was in a period of consolidation at that point, and stores were being closed on a weekly basis. Perhaps the requirement could be dropped in favor of comparing against a regular expression? That wouldn't work, though, because one of the key reasons for validating was ensuring that the stores in question were legitimate, and moreover that they hadn't been closed. In the end, the developed solution was a kludge—post process the XML against a list retrieved directly from a database call on the server itself.

The same issue reared its ugly head more recently while working with schema-generated XForms, prompting a lot of thought about the nature of lists and their relationship to models. At their most fundamental, all lists ultimately have two things in common. First, a list is a sequence of objects. Second, and more importantly, for each object in the list, there is a key that is unique to that item identifying the object within the list. In an indexed area, that key is a number (usually zero or one based) that identifies the items by position. The "name" of that item (this key) is then unique only to the context of the array—known as a linear array—and only if the array itself doesn't change in the sequence leading up to that number.

For instance, consider this simple list of colors:

colors = ['red', 'orange', 'yellow', 'green', 'blue', 'violet']

The list can be exposed as a sequential list with numeric keys, conceptually the same as:

colors = {0 : 'red', 1 : 'orange', 2 : 'yellow', 3 : 'green', 4 : 'blue', 5 : 'violet'}

Such a system implies that you can effectively access the given resource by its index (or similarly update the content by assigning it to the indexed entry):

print colors[0]
=> red
colors[0] = 'scarlet'
print colors[0]
=>scarlet

An associative array, on the other hand, associates a formal name to a given term in the list:

colors = {rd : 'red', or : 'orange', ye : 'yellow', gn : 'green', bu : 'blue', vi : 'violet'}

You can then reference a given element from the array through the associated name:

print colors['rd']
=> red
colors['rd'] = 'scarlet'
print colors['rd']
=> scarlet

In this case, the set of all keys in the associated array effectively make up a taxonomy. Note that it is the keys, not the contents, of the array that are more important here, especially because there is no specific prohibition on the contents being anything—up to and including other arrays.