Why are simple code lists so complex?

Keywords: CCTS, Code list, Data interchange, Data representation, Database, ebXML, FpML, ISO, ISO 20022, MDDL, UBL

Anthony B. Coates
LMS
Chief Architect
London Market Systems Ltd
London
United Kingdom
abcoates@londonmarketsystems.com

Biography

Anthony B. Coates (Tony) specialises in information management and integration solutions for financial and corporate clients. Tony is Chief Architect for London Market Systems, and previously was Leader of XML Architecture and Design in Reuters Chief Technology Office in London. Tony has worked as an architect for a number of financial XML initiatives, including MDDL (Market Data Definition Language, http://www.mddl.org/) and FpML (Financial Products Markup Language). Tony is also an editor of the MDDL specification. Tony's background includes developing software for technical analysis and financial graphics, developing multimediaand Web applications, and theoretical and experimental physics. He has worked with XML since 1998, and Java since 1996. Tony is a past secretary of the Australian Java Users Group.

Abstract

Code lists, or enumerated values, have been with us since long before computers. They should be well understood and easily dealt with by now. Unfortunately, they are not. As is so often the case, if you take a fundamentally simple concept, you find that everyone professes to understand it with crystal clarity. When you look more closely, you find that everybody has their own unique view of what the problem is and how it should be solved. Getting to a broadly applicable solution in these cases can be a long, slow struggle.

This presentation examines the ways code lists are used, based on the author's experience with a number of XML standards, including ebXML/UBL, ISO 20022, FpML, and MDDL. This is further extended beyond the needs (and mindsets) of XML to the general requirements of applications. A sufficiently complex method for managing simple code lists is then proposed.

1. Introduction
2. What a difference a day makes
3. Turning the tables on code lists
4. The code list is in the eye of the beholder
5. The only constant is change
6. Keeping it real
7. I'm a model, you know what I mean
     7.1 Column sets
     7.2 Code lists
          7.2.1 Simple code lists
          7.2.2 Derived code lists
     7.3 Sets of code lists
8. Example code list document
9. Conclusion
Appendix 1. Requirements for thegenericode code list format
Appendix 2. Sample FpML scheme
Appendix 3. Sample MDDL scheme
Appendix 4. Sample UBL code list Schema
Appendix 5. Code list and column set WXS Schema

1. Introduction

It is said that it takes only a minute to decide to spend a million dollars, because nobody really understands what a million dollars is. However, people can argue about the choice of office paperclips for hours, because everybody is an expert on paperclips. Code lists (enumerated values) are similar, because they are so obviously simple, and everyone knows everything about them.

If code lists were really so simple and obvious, there would be a single, well-known and accepted way of handling them in XML. There is no such agreed solution, though. The problem is that while code lists are a well understood concept, people don't actually agree on exactly what code lists are, and how they should be used.

2. What a difference a day makes

What is a code list, then? Most people would agree that the following is a code list:

{'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'}

Example 1: Days of the week: english, uppercase

This is a perfectly reasonable set of alphabetic codes for representing days of the week. However, so is:

{'Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'}

Example 2: Days of the week: english, mixed case

These two code lists are very similar, but certainly not identical. That said, they can both be used to represent the days of the week. Of course, you could also use:

{'Dim', 'Lun', 'Mar', 'Mer', 'Jeu', 'Ven', 'Sam'}

Example 3: Days of the week: french, mixed case

which is created from abbreviations for the days of the week in French. Then again, you could use:

{0, 1, 2, 3, 4, 5, 6}

Example 4: Days of the week: numeric

which is suitable as a computer representation, e.g. for a database column. On the other hand:

{'S', 'M', 'T', 'W', 'T', 'F', 'S'}

Example 5: Days of the week: english, single character

is not suitable as a code list for the days of the week, because the values are not unique.

Now suppose that you are using codes to represent days of the week in an application, and you are displaying the days of the week using 3-letter abbreviations in English or French. In that context, should Example 2 and Example 3 be considered to be code lists, or should they be considered to be display values that would be keyed to either the Example 1 or Example 4 codes? The fact is, they could be either code lists or display values. A value which is a code in one context might only be an associated value for that code in another context. Nothing privileges any of these code lists over the others in terms of ability or suitability to be the code list (except the Example 5 values which are not suitable). There is a choice of code lists that can be used, and the answer to the question "which choice is the best?" depends on the needs of each particular situation.

3. Turning the tables on code lists

What the examples in Chapter 2 showed was that for each conceptual code in a list, there are many possible associated values (we use the term conceptual code to express the idea that we are talking a single item that needs to be represented in the code list, rather than about any of the particular codes that can be used to identify that item). Some of those associated values are suitable for use in code lists, some are not. This leads to a tabular model, where each row of the table represents a conceptual code, and each column represents an associated value, as follows:

numeric (key)	english, uppercase (key)	english, mixed case (key)	french, mixed case (key)	english, single character
0	SUN	Sun	Dim	S
1	MON	Mon	Lun	M
2	TUE	Tue	Mar	T
3	WED	Wed	Mer	W
4	THU	Thu	Jeu	T
5	FRI	Fri	Ven	F
6	SAT	Sat	Sam	S

Table 1: Days of the week

Notice that the first 4 of the 5 columns have been labelled as 'key' columns. This means that the values in those columns can be used to uniquely identify the rows, and hence they can be used as code list values. The term key is used here is the same fashion as for a relational database table.

This is the most common case, where a single column can be used as a key. However, consider the following modification:

numeric (key)	english, uppercase (key)	english, single character #1	english, single character #2
0	SUN	S	U
1	MON	M	O
2	TUE	T	U
3	WED	W	E
4	THU	T	H
5	FRI	F	R
6	SAT	S	A

Table 2: Days of the week, version 2

Here, the first two columns are each a key column. The last two columns are not individually key columns, but together they form a compound key, i.e. while the individual columns do not contain unique values, the pair of values is unique within each row. This is again similar to what happens in some relational databases, that a key for the rows need not be constructed from a single column, but instead may be constructed by combining two or more columns.

Finally, there is no reason why a column should only contain simple values like strings or numbers. A column could also contain a complex compound group of data, such as a fragment of XML:

numeric (key)	english, uppercase (key)	XHTML
0	SUN	<a href="http://days.of.week/SUN"><b>Sunday</b></a>
1	MON	<a href="http://days.of.week/MON"><i>Monday</i></a>
2	TUE	<a href="http://days.of.week/TUE"><b>Tuesday</b></a>
3	WED	<a href="http://days.of.week/WED"><i>Wednesday</i></a>
4	THU	<a href="http://days.of.week/THU"><b>Thursday</b></a>
5	FRI	<a href="http://days.of.week/FRI"><i>Friday</i></a>
6	SAT	<a href="http://days.of.week/SAT"><b>Saturday</b></a>

Table 3: Days of the week, version 3

Notice that the final XHTML column is not marked as a key column. The values are unique, so it certainly could be used as a key column. However, sometimes you may not wish to mark a column as a key column, even if the values are unique. The values in the column may not make particularly suitable keys. They might be too long to process quickly and conveniently, or they might not be able to be used in a particular context, such as for an XML attribute value. Also, it may be that while the values in a particular column are unique now, there is no guarantee or expectation that they will remain unique as the code list grows or changes in future.

4. The code list is in the eye of the beholder

Once you see the tabular nature that underlies the information that can be associated with code lists, it becomes clear why they can be a source of so much debate. Different users need different subsets of the code list information, and people are inclined to assume that the information they need is all the information that anyone needs.

That kind of thinking doesn't work with code lists, because code lists are sufficiently generic a concept that they are used across messages/documents, applications, and databases. The code list details that you need for the XML schemata often will not be exactly the same as the details that you need for your database or your application. If the code list information cannot be shared easily across these different areas of the business, the result is duplication of effort and potential loss of synchronisation between different implementations of the same code list.

The XML schema may only require a set of 3-letter codes to represent the code list. The database may require a set of numeric codes, plus display labels (possibly in different languages). The application may need to know which 3-letter code corresponds to which numeric code, so that it can process the XML and update the database. All of this code list information needs to be able to be stored together in a single representation of the code list, so that all usages of the code list can be generated from the same source information. For this paper, a canonical XML format for code lists will be presented, as there needs to be a suitable format for interchange of code lists. Note that this does not preclude the use of an equivalent canonical database model, for example, to provide the central code list information repository for an organisation. Also, some information related to a code list might not be appropriate for the XML format. For example, if you have a different image file for each code, it isn't ideal to include this image inline in the code list XML, since it vastly increases the size of the XML, and makes it more difficult to read. So in an XML representation, you are more likely to include some reference (e.g. a URL) to the image. For a database, however, it may be feasible to store the image in a BLOB column in the database.

One last piece of experience from databases is that support for undefined values will be required. Sometimes users will have values that need to be associated with some of the codes in a code list, but won't have values for each code. In that case, the concept of a undefined value is needed.

5. The only constant is change

Code lists change. One thing that distinguishes code lists from some other data used in applications is that applications can often continue to run correctly if a code list is changed. By contrast, your application is likely to fail if you change a complex data structure and don't update the application accordingly. Changes to code lists can nonetheless cause an application to fail if any of the application code requires a specific value to exist in the code list, or if it requires that a specific value does not exist.

The upshot, though, is that for a code list model to be useful, it has to account for the fact that the code lists will change over time. There is little use in having a code list model that works for a code list that is frozen in time, but not for a code list that changes over time. So the code list model has to support changes between versions of a code list.

Not all changes to a code list are version changes. Some changes may be local changes to a distributed code list. For example, the ISO 3-letter currency code list contains 'GBP' for British Pounds. However, prices on the London Stock Exchange are normally quoted in pence, not pounds. This has led to the practice of adding an extra code to the standard ISO list (e.g. 'GBp', 'GBX') in order support pence as well as pounds. This kind of customisation is far from uncommon, and the utility of any code list model is greatly reduced if it does not cater for local modifications of code lists. In terms of the tabular model of code lists used in Chapter 3, the following are typical local customisations:

Add or remove a row (the set of values associated with a conceptual code);
Add or remove a column (a type of value associated with each conceptual code);
Add or remove a key. Adding a key involves specifying the column(s) to be used for the key;
Add one or more rows from a set of code lists together. This implies that the columns are the same, or that null values will be used as required;
Add one or more columns from a set of code lists together. This implies that there is at least one key in common in each row, and that there are no keys with conflicting values;
Remove rows for which a key value matches the key value in another code list (this can be used to delete a particular pre-defined subset of the codes);
Modify a cell value (one of the values associated with a code). Note that this may impact whether the affected column can be used as a key or not;
Create a derived column whose values are generated from the values in other columns.

In addition to being able to make local customisations, there should be a way for users to understand easily how their local code list was derived from one or more other code lists. This means that the code list model needs to be able to model the ways that code lists are modified, and not just provide a model for code lists that are self-contained and independent of other code lists.

There are a couple of other potential requirements that are important, but aren't addressed in the model presented here. One is the ability to trace how a code list has changed over time, and how it will change in the future, so that you can determine the content of the code list at any point in time, past or future. A good reference for this topic is Martin Fowler's Patterns for things that change with time.

The other requirement is to allow for code lists that cannot be enumerated. This can be because the list is too large or quickly changing to be enumerated feasibly in a static document, or it can be because the code list is proprietary and its users are not licensed to see the entire entire contents of the code list. What is required for this situation is a protocol (e.g. a Web service or API) that allows a set of codes to be checked against the code list, with the result containing a yes/no indication for each checked code. Again, this is not a requirement that is yet addressed in the model presented here.

6. Keeping it real

The initial impetus for looking at how to represent code lists came from two financial XML specifications, FpML (Financial Products Markup Language) and MDDL (Market Data Definition Language). FpML defined the approach of keeping enumerations out of the core Schema by using schemes. The idea is that the code list from which an element value is taken is indicated via a scheme attribute containing a URI which represents the scheme (code list), in the same way that URIs are used to represent XML namespaces. This was done so that a new version of FpML did not have to be released just because an enumeration had changed (e.g. a currency or country code). Also, it made it straightforward for groups of users to use alternate code lists as appropriate.

<Currency
 scheme="http://www.fpml.org/ext/iso4217-2001-08-15"
>USD</Currency>

One thing that FpML never formally defined was what happens if you dereference a scheme URI (i.e. type it into a Web browser). They have only defined a draft XML format for the contents of a scheme.

MDDL copied the FpML scheme approach. Like FpML, it does not have a formally defined scheme format, and has a (different) draft XML format for schemes. So, a key aim of this generic code list model is to produce a format that can be shared by FpML and MDDL, or can be used as a common base format from which they can both generate whatever XML scheme format they may ultimately decide to use. A sample FpML scheme is shown in Appendix 2, while a sample MDDL scheme is shown in Appendix 3.

Note that no XML schema language currently supports the notion of schemes in this sense, so applications have to implement their own validation of codes against schemes at present.

Around the same time, UBL (Univeral Business Language), an OASIS offshoot of ebXML (Electronic Business using eXtensible Markup Language), which is a combined UN/CEFACT and OASIS effort, was working on its own approach to code lists, so it again seemed like a good idea to try and unify all of these efforts, and reduce the duplication. UBL uses a more formal approach to code lists, in line with the CCTS (Core Components Technical Specification) methodology from the ebXML framework. In terms of the tabular model of code lists used in Chapter 3, UBL code lists have the following columns:

Content — A character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute. This is what you normally would refer to colloquially as 'the code'.
CodeName — (optional) The textual equivalent of the code content.
CodeDescription — (optional) A description of the code.
CodeIndex — (optional) A unique numeric index for the code.

UBL code lists also have metadata describing the code list as a whole: what it is, who publishes it, etc. So the code list model needs to support metadata describing the code list, as well as to provide a table of values for the codes themselves. A sample W3C XML Schema for a UBL code list is shown in Appendix 4..

7. I'm a model, you know what I mean

What follows is a model for code lists, one which covers many (though not yet all) of the requirements that have been outlined. From the model comes an XML format for code lists. The intention of this format is that it can be used to encode and transmit code lists. It could be used as a run-time format from which codes are looked up directly, but it is probably more likely to be used as a source from which various run-time representations of code lists can be produced, such as XML schemata, relational database schemata, and programming language enumerations.

My preferred approach to producing physical artifacts like XML schemata is to produce a logical (non-XML) model of my solution first, and then create the schema(ta) based on the model. For the modelling, I like to use UML (Unified Modelling Language,), which provides a convenient graphical notation for data-oriented modelling. The model here is intended to cover most of the code list requirements outlined in Chapter 5. However, it does not cover temporal variations, nor does it cover non-enumerable code lists. It also doesn't provide a simple way to change an individual cell in a tabular code list, as it is better to change a whole row of column of a code list in one operation so that there is a more obvious context to the change. It also doesn't provide support for columns that are derived from other columns in some automated fashion.

Broadly speaking, the model is divided into 4 sections:

column sets (columns and keys);
simple code lists;
derived code lists;
sets of code lists.

The code list model is implemented here as a W3C XML Schema (WXS). The Schema can be used to encode either a column set (with ColumnSet as the root element) or a simple or derived code list (with CodeList as the root element), or a set of code lists (with CodeListSet as the root element). The full Schema is shown in Appendix 5.

7.1 Column sets

A column set of a set of columns and keys for a code list table.

Figure 1: Column set model

Each column set must have a unique ID. A column set can define any number of columns. It can also reference any number of columns from other column sets. A column set can also define any number of keys. Each key is defined by one or more of the columns in the column set (either defined or imported). Keys are used to uniquely identify the rows (conceptual codes) of code lists. Columns and keys are uniquely named within the column set that defines them.

The matching WXS representation of a column set definition is:

Figure 2: Column set WXS model — Identification detail

This figure is in TurboXML™ notation. A column set definition contains optional user annotation information (Annotation), and then identification and location information (Identification). A column set has a short name and any number of long names. It is uniquely identified by a canonical URI. Particular versions of the column set are uniquely identified by a canonical version URI. Location URIs can also be provided to suggest URLs from which an XML column set instance may be retrieved (at the discretion of an application).

Figure 3: Column set WXS model — Column detail

A column definition (Column) contains an ID for the column and its use (required or optional). It also contains a short name (token) for the column, and any number of long names. The datatype information for the column is contained in its Data element.

Figure 4: Column set WXS model — Data detail

The Data structure is based on the data element in RELAX NG. The datatype is specified as a Type from a DatatypeLibrary. If the datatype library is not specified, it is inherited from the DatatypeLibrary attribute of the enclosing column set definition. It otherwise defaults to the WXS datatype library.

If the data is XML, and not a simple data type, the DataTypeLibrary should be set to the namespace URI for the XML (content without an explicit namespace is discouraged), and the Type should be set to the top-level global element name for the XML data.

Data definitions can contain Parameter elements which define facets that refine the datatype. When using the WXS datatype library, these are just the usual WXS datatype facets.

Figure 5: Column set WXS model — ColumnRef detail

If a column is defined in an external column set or code list document, it can be referred to using a ColumnRef. The column reference must have an ID just as a column definition would, but it also has an ExternalRef which contains the column's ID in the external document. The external column set or code list is identified by a CanonicalVersionUri and/or by any LocationUri information that is provided.

Figure 6: Column set WXS model — Key detail

A key definition (Key) contains an ID for the key. It also contains a short name (token) for the key, and any number of long names. The columns which together form the key are referenced using one or more ColumnRef elements. The Ref attribute of each contains the ID of either a Column or ColumnRef in the column set. Only required (not optional) columns may be used within a key, but this rule is not able to be enforced using the WXS Schema alone.

Figure 7: Column set WXS model — KeyRef detail

If a key is defined in an external column set or code list document, it can be referred to using a KeyRef. The key reference must have an ID, and also has an ExternalRef which contains the key's ID in the external document. The external column set or code list is identified by a CanonicalVersionUri and/or by any LocationUri information that is provided.

7.2 Code lists

With the column set model established, we can move to the rest of the code list model. A code list can define its own column set. It can also import columns and keys from any number of external column sets. In the simplest case, what a code list provides is a set of rows, where each row defines a conceptual code in the code list. This is a Simple CodeList. However, what is commonly required is to create a new code list based on the content of one or more existing code lists. What this model of code lists provides, beyond the simple tabular model of a code list, is support for modelling a Derived CodeList, where the steps in the derivation are modelled so that they can be audited and repeated.

Figure 8: Code list model

First we will look at the Simple CodeList model, and then at the Derived CodeList model.

7.2.1 Simple code lists

A Simple CodeList is modelled as follows:

Figure 9: Simple code list model

A Simple CodeList contains zero or more rows (it is necessary to support empty code lists to allow for code lists that are empty now, but will be populated in future versions). Each Row defines a conceptual code in the code list.

A Row contains one or more values, one for each column in the code list. At least one value is required, because a code list has to have at least one key, and each key requires at least one column. So a code list must have at least one column, and a Row must have at least one Value. This is an indirect constraint on the number of colums in a code list which may not be immediately obvious from the UML model.

Each Value is associated with a single column of the code list. For each Key in the code list, the values associated with the columns for that key must form a unique set, i.e. no two rows are allowed to have the same set of values for the same key columns. Note that this uniqueness requirement cannot be enforced using (only) the WXS Schema for the code list model, which follows:

Figure 10: Simple code list WXS model

Many of these elements have appeared already in Section 7.1, so the explanations will not be repeated here. A code list can either define its own ColumnSet, or refer to an externally defined column set using ColumnSetRef.

Figure 11: Simple code list WXS model — ColumnSetRef detail

A ColumnSetRef contains the canonical version URI which uniquely identifies the referenced column set or code list. It can also contain suggested URLs from which to retrieve the column set or code list.

Some simple code lists are used to hold the results of deriving a code list. When this is the case, a DerivedCodeListRef is used to indicate the related derived code list.

The WXS model of a SimpleCodeList is

Figure 12: Simple code list WXS model — SimpleCodeList detail

A SimpleCodeList contains zero or more Row elements. Each Row contains one or more Value elements. The Value container element is needed to allow optional user annotations of individual values in the code list. It has a ColumnRef attribute which contains the unique document ID of the associated column. It then contains either a SimpleValue containing a textual value, or a ComplexValue containing a balanced XML fragment.

Note that the ColumnRef attribute of a Value is optional. If it is not provided, it is assumed that the column is the one which follows the column associated with the previous value in the row. If the first Value in a Row does not have a ColumnRef, it is assumed to be associated with the first column in the column set. It is an error if a row contains more than one value for the same column, or if it does not contain a value for a required column.

7.2.2 Derived code lists

Derived code lists are actually descriptions of the steps involved in deriving a code list from one or more source code lists and column sets. They allow the derivation of one code list from one or more others to be understood, audited, and accurately repeated.

Each step in the derivation of a code list yields an intermediate derived code list, which is then an input to the following derivation step. This means that each step in a code list derivation can be modelled using a subclass of Derived CodeList.

The first group of these are the row filters. These remove rows from the source code list.

Figure 13: Derived code list model — row filters

A Row Filter CodeList is a CodeList containing a subset of the rows in the source code list, based on comparison with the control code list. The columns and keys of the derived code list are the same as in the source code list. The control code list must contain a (non-empty) subset of the keys in the source code list, and must contain only those columns required for the keys in the control code list.

A Row Inclusion CodeList contains those rows from the source code list which have all of the same key values as a row in the control code list, for those keys in the control code list.

A Row Match CodeList is a Row Inclusion CodeList for which it is an error if any of the rows in the control code list does not have the same key values as one of the rows in the source code list. This is used to guarantee that particular rows exist in the source code list.

A Row Exclusion CodeList contains those rows from the source code list which do not have any of the same key values as any of the rows in the control code list.

Figure 14: Derived code list model — row unions

It is necessary to be able to add rows as well as remove them. A Row Union CodeList contains the union of the rows from all of the source code lists. Each of the source code lists must have the same keys and columns. It is an error if any two rows have all the same key values, but different values in any of the columns.

Figure 15: Derived code list model — column set filters

Just as rows can be filtered, so can columns and keys. A Column Filter CodeList is a CodeList containing a subset of the columns/keys in the source code list, based on comparison with the control column set. The rows of the derived code list are the same as in the source code list. The control column set must contain a (non-empty) subset of the columns and keys in the source code list. The control column set must contain all columns required for the keys in the control column set.

A Column Inclusion CodeList contains those columns and keys from the source code list which appear in the control column set.

A Column Match CodeList is a Column Inclusion CodeList for which it is an error if any of the columns or keys in the control column set is not part of the source code list. This is used to guarantee that particular columns/keys exist in the source code list.

A Column Exclusion CodeList contains those columns/keys from the source code list which do not appear in the control column set. However, columns in the control column set are not excluded if they are required for keys which are not in the control column set. It is an error if all keys in the source code list are excluded.

Figure 16: Derived code list model — column set unions

A Column Union CodeList contains the union of the columns and keys from all of the source code lists. Each pair of source code lists must have at least one key in common. Rows from each source code list are merged with any rows from the other source code lists with which they share one or more keys. It is not necessary for all code lists to have the same number of rows. However, it is an error if the union leads to an undefined value in any required column of a row, or if the union leads to two or more different values for the same column in a row.

These different kinds of code list derivation can be applied in an appropriate sequence to create the desired derived code list. The WXS Schema representation is as follows:

Figure 17: Derived code list WXS model

The DerivedCodeList element contains (after an optional Annotation) a single element which defines the kind of derivation. Column filter elements (ColumnSetExclusion, ColumnSetInclusion, ColumnSetMatch) each contain a Source element (of type InputCodeList) and a Control element (of type InputColumnSet). Row filter elements (RowExclusion, RowInclusion, RowMatch) each contain a Source element (of type InputCodeList) and a Control element (of type InputCodeList). Union elements (ColumnSetUnion, RowUnion) each contain one or more Source elements (of type InputCodeList).

Figure 18: Derived code list WXS model — InputCodeList & InputColumnSet

An element of type InputCodeList can contain a simple code list definition, a derived code list definition, or a reference to an external code list (either simple or derived). An element of type InputColumnSet can contain either a column set definition or a reference to an external column set or code list.

This recursive structure allows a single derived code list document to contain an arbitrarily complex set of derivation steps, with source/control inputs either defined explicitly or referenced from external documents.

7.3 Sets of code lists

Any version of a standard, or any version of an application, will typically be associated with particular versions of a number of code lists. In order to be able represent such a configuration versions, a CodeListSet element can be used as the root element to identify a related set of code list versions.

Figure 19: Code list set WXS model

Note that a code list set does not contain definitions of code lists, it only refers to the code list versions which are a part of (that version of) the code list set. It should also be noted that a code list set may contain a reference to a code list version without specifying a location for a definition of that code version. This is allowable where (a) the code list definition is known to the users, and no location needs to be published, or (b) the code list is sufficiently well-known (e.g. ISO 3-letter country codes), so that users simply need to have it uniquely identified, and do not need to have it enumerated for them.

8. Example code list document

Here is the example UBL code list from Appendix 4, expressed using the code list WXS Schema defined in this paper (see Appendix 5).

Please be aware that this sample has been wrapped to fit with a 75 character width limit, and will not be valid without slight reformatting.

<?xml version = "1.0" encoding = "UTF-8"?>
<gcl:CodeList xmlns:gcl="http://xml.genericode.org/2004/ns/CodeList/0.2/"
 xmlns:ccts=
 "urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0">
 <Identification>
  <ShortName>CountryIdentificationCode</ShortName>
  <Version>1.0</Version>
  <CanonicalUri>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode
  </CanonicalUri>
  <CanonicalVersionUri>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0
  </CanonicalVersionUri>
 </Identification>
 <ColumnSet>
  <Column Id="CountryIdentificationCodeContent" Use="required">
   <ShortName>CountryIdentificationCodeContent</ShortName>
   <Data Type="token"/>
  </Column>
  <Column Id="CodeName" Use="required">
   <ShortName>CodeName</ShortName>
   <Data Type="string"/>
  </Column>
  <Key Id="CountryIdentificationCodeContentKey">
   <ShortName>CountryIdentificationCodeContentKey</ShortName>
   <ColumnRef Ref="CountryIdentificationCodeContent"/>
  </Key>
 </ColumnSet>
 <SimpleCodeList>
  <Row>
   <Value ColumnRef="CountryIdentificationCodeContent">
    <SimpleValue>AD</SimpleValue>
   </Value>
   <Value ColumnRef="CodeName">
    <SimpleValue>ANDORRA</SimpleValue>
   </Value>
  </Row>
  <Row>
   <Value ColumnRef="CountryIdentificationCodeContent">
    <SimpleValue>ZW</SimpleValue>
   </Value>
   <Value ColumnRef="CodeName">
    <SimpleValue>ZIMBABWE</SimpleValue>
   </Value>
  </Row>
 </SimpleCodeList>
</gcl:CodeList>

Now a second version which includes the application information (metadata) that UBL assigns to code lists (prefixed with ccts). Some of this code list information may be integrated into a future version of the code list Schema's Identification element.

<?xml version = "1.0" encoding = "UTF-8"?>
<gcl:CodeList xmlns:gcl="http://xml.genericode.org/2004/ns/CodeList/0.2/"
 xmlns:ccts=
 "urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0">
 <Annotation>
  <AppInfo>
   <ccts:Component>
    <ccts:ComponentType>DT</ccts:ComponentType>
    <ccts:DictionaryEntryName>
Country Identification_ Code. Type
    </ccts:DictionaryEntryName>
    <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
    <ccts:DataTypeQualifier>
Country Identification
    </ccts:DataTypeQualifier>
    <ccts:DataType>Code. Type</ccts:DataType>
   </ccts:Component>
   <ccts:Instance>
    <ccts:CodeListID>ISO3166-1</ccts:CodeListID>
    <ccts:CodeListAgencyID>6</ccts:CodeListAgencyID>
    <ccts:CodeListAgencyName>
United Nations Economic Commission for Europe
    </ccts:CodeListAgencyName>
    <ccts:CodeListName>Country</ccts:CodeListName>
    <ccts:CodeListVersionID>0.3</ccts:CodeListVersionID>
    <ccts:CodeListURI>
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/li
st-en1-semic.txt
    </ccts:CodeListURI>
    <ccts:CodeListSchemeURI>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0
    </ccts:CodeListSchemeURI>
    <ccts:LanguageID>en</ccts:LanguageID>
   </ccts:Instance>
  </AppInfo>
 </Annotation>
 <Identification>
  <ShortName>CountryIdentificationCode</ShortName>
  <Version>1.0</Version>
  <CanonicalUri>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode
  </CanonicalUri>
  <CanonicalVersionUri>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0
  </CanonicalVersionUri>
 </Identification>
 <ColumnSet>
  <Column Id="CountryIdentificationCodeContent" Use="required">
   <ShortName>CountryIdentificationCodeContent</ShortName>
   <Data Type="token"/>
  </Column>
  <Column Id="CodeName" Use="required">
   <ShortName>CodeName</ShortName>
   <Data Type="string"/>
  </Column>
  <Key Id="CountryIdentificationCodeContentKey">
   <ShortName>CountryIdentificationCodeContentKey</ShortName>
   <ColumnRef Ref="CountryIdentificationCodeContent"/>
  </Key>
 </ColumnSet>
 <SimpleCodeList>
  <Row>
   <Value ColumnRef="CountryIdentificationCodeContent">
    <SimpleValue>AD</SimpleValue>
   </Value>
   <Value ColumnRef="CodeName">
    <SimpleValue>ANDORRA</SimpleValue>
   </Value>
  </Row>
  <Row>
   <Value ColumnRef="CountryIdentificationCodeContent">
    <SimpleValue>ZW</SimpleValue>
   </Value>
   <Value ColumnRef="CodeName">
    <SimpleValue>ZIMBABWE</SimpleValue>
   </Value>
  </Row>
 </SimpleCodeList>
</gcl:CodeList>

9. Conclusion

In this paper, we have examined the reasons why code list models are often too narrow. A tabular model of a code list, designed to cover a broad range and requirements and usages, has been presented. In particular, the model captures the fact that code lists may be represented by different sets of codes in different circumstances, and that the choice of what is the code and what is associated content can change from one usage to another. The model presented here is also capable of representing the steps required to derive a code list from a set of existing code lists, so that relationships between code lists are auditable, and derivations are repeatable.

Be aware that the work presented here is still an early draft, and some items will certainly change as the model and associated WXS Schema are refined. Also, the work will not be complete until there is a reference software implementation that can process a derived code list definition to produce the equivalent simple code list.

This paper was produced with the aid of the following software:

Syntext Serna 2.0: WYSIWYG XML editor;
Enterprise Architect 4.10: UML editor;
Century 24 Integration Objects 3.0.0: WXS Schema model editor, repository and generator;
Tibco TurboXML 2.3: WXS Schema editor and diagram generator;
jEdit 4.2: XML editor and formatter.

Appendix 1. Requirements for the`genericode` code list format

What follows is a list of the requirement which led to the current design of the genericode code list format.

The format should be appropriate for use across a range of standards activities, i.e. it should embody the most generic view of code lists, and not any particular group's specific view. It should also be useful for implementations of those standards, not just for the standards activity itself.
The format should be interchangeable and machine processable across a broad range of systems.
The format should support the full complexity of code lists, but should not make it complex to define a simple code list (i.e. just a single set of codes, with no other associated values).
The format should allow multiple values to be associated with a single (notional) code in a code list.
The format should allow any unique set of values associated with the codes in a code list to be used as a key (the 'code' in common parlance) for the code list.
The format should not make assumptions about how many different keys can be used to uniquely identify (notional) codes in a code list, nor should it privilege any one key above any other. Choice of a particular key is considered to be a late decision that is made to suit a particular application context, and is outside of the scope of the generic representation of the code list.
The format should require each code list to have at least one key.
The format should make provision for deriving new code lists from existing code lists. This includes adding/removing (notional) codes, and adding/removing sets of values associated with the code list. It also includes adding/removing keys.
Where a new code list is derived from an existing code list, the derivation should be repeatable and auditable.
The format should support the existence of multiple versions of the same code list, and should allow an auditable derivation of each new version from the previous version.
The format should allow all code lists, and all versions of code lists, to be uniquely identified in a machine processable manner.
The format should allow machine readable and human readable metadata to be added to code lists, and also to individual codes, keys, and associated values in a list.
The format should allow sets of related code lists (code list versions) to be published together (for configuration management purposes).
With a code list set, it should be possible to identify a (well-known) code list that may not have a genericode definition. For example, it may be sufficient to refer to the ISO 3-letter country codes without having them available in a genericode definition.

Requirements which have not yet been implemented are:

The format should support code lists which can not be enumerated in their entirety (for legal or practical reasons).
Human readable text (in metadata or associated values) should support the xml:lang attribute.

Appendix 2. Sample FpML scheme

The following is an abbreviated version of the FpML country code scheme. All but two of the country codes have been removed, for brevity. Note that the FpML format allows multiple schemes (code lists) to be defined in the one file.

<?xml version="1.0" encoding="utf-8"?>
<schemeDefinitions>
 <scheme name="countryScheme" uri="http://www.fpml.org/ext/iso3166">
  <schemeValue name="AD" schemeValueSource="ISO">
   <paragraph>Andorra, Principality of</paragraph>
  </schemeValue>
  <schemeValue name="ZW" schemeValueSource="ISO">
   <paragraph>Zimbabwe</paragraph>
  </schemeValue>
 </scheme>
</schemeDefinitions>

The simplest translation into genericode format, assuming a 2004 edition of the ISO 3166 country codes, is

<?xml version="1.0" encoding="utf-8"?>
<gcl:CodeList xmlns:gcl="http://xml.genericode.org/2004/ns/CodeList/0.2/"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xml.genericode.org/2004/ns/CodeList/0.2/
  CodeList.xsd">
 <Identification>
  <ShortName>countryScheme</ShortName>
  <LongName>ISO3166 2-letter country codes</LongName>
  <Version>2004</Version>
  <CanonicalUri>http://www.fpml.org/ext/iso3166</CanonicalUri>
  <CanonicalVersionUri>
   http://www.fpml.org/ext/iso3166/2004
  </CanonicalVersionUri>
 </Identification>
 <ColumnSet>
  <Column Id="CountryCode" Use="required">
   <ShortName>code</ShortName>
   <Data Type="token"/>
  </Column>
  <Column Id="CountryName" Use="optional">
   <ShortName>name</ShortName>
   <Data Type="string"/>
  </Column>
  <Key Id="PrimaryKey">
   <ShortName>key</ShortName>
   <ColumnRef Ref="CountryCode"/>
  </Key>
 </ColumnSet>
 <SimpleCodeList>
  <Row>
   <Value><SimpleValue>AD</SimpleValue></Value>
   <Value><SimpleValue>Andorra, Principality of</SimpleValue></Value>
  </Row>
  <Row>
   <Value><SimpleValue>ZW</SimpleValue></Value>
   <Value><SimpleValue>Zimbabwe</SimpleValue></Value>
  </Row>
 </SimpleCodeList>
</gcl:CodeList>

Appendix 3. Sample MDDL scheme

The following is an abbreviated version of the MDDL country code scheme. All but two of the country codes have been removed, for brevity. Also, please be aware that this example has been wrapped to fit with a 75 character width limit.

<?xml version="1.0" encoding="utf-8"?>
<mddlScheme>
 <head>
  <dateTime>2003-04-04T180000Z</dateTime>
  <title>ISO 3166 - Country Codes (2-char)</title>
  <element>code</element><parent wildcard="yes"/>
  <definition>ISO 3166 Country Code Identifiers - 2-character alphabetic
abbreviations</definition>
  <uri>http://www.mddl.org/ext/scheme/iso3166-alpha-2.xml</uri>
  <note>This file is provided as a convenience and may or may not contain
the current official codes.</note>
 </head>
 <value>
  <short>AF</short>
  <full>AFGHANISTAN</full>
 </value>
 <value>
  <short>ZM</short>
  <full>ZAMBIA</full>
 </value>
</mddlScheme>

The simplest translation into genericode format is

<?xml version="1.0" encoding="utf-8"?>
<gcl:CodeList xmlns:gcl="http://xml.genericode.org/2004/ns/CodeList/0.2/"
 xmlns:doc="http://www.mddl.org/example/scheme/documentation"
 xmlns:info="http://www.mddl.org/example/scheme/information"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xml.genericode.org/2004/ns/CodeList/0.2/
  CodeList.xsd">
 <Annotation>
  <Description>
   <doc:definition>ISO 3166 Country Code Identifiers - 2-character
    alphabetic abbreviations</doc:definition>
   <doc:note>This file is provided as a convenience and may or may not
    contain the current official codes.</doc:note>
  </Description>
  <AppInfo>
   <info:dateTime>2003-04-04T180000Z</info:dateTime>
   <info:element>code</info:element>
   <info:parent wildcard="yes"/>
  </AppInfo>
 </Annotation>
 <Identification>
  <ShortName>iso3166-alpha-2</ShortName>
  <LongName>ISO 3166 - Country Codes (2-char)</LongName>
  <Version>2003-04-04T180000Z</Version>
  <CanonicalUri>
   http://www.mddl.org/ext/scheme/iso3166-alpha-2
  </CanonicalUri>
  <CanonicalVersionUri>
   http://www.mddl.org/ext/scheme/iso3166-alpha-2/2003-04-04T180000Z
  </CanonicalVersionUri>
  <LocationUri>
   http://www.mddl.org/ext/scheme/iso3166-alpha-2.xml
  </LocationUri>
 </Identification>
 <ColumnSet>
  <Column Id="ShortName" Use="required">
   <ShortName>code</ShortName>
   <Data Type="token"/>
  </Column>
  <Column Id="FullName" Use="optional">
   <ShortName>name</ShortName>
   <Data Type="string"/>
  </Column>
  <Key Id="PrimaryKey">
   <ShortName>key</ShortName>
   <ColumnRef Ref="ShortName"/>
  </Key>
 </ColumnSet>
 <SimpleCodeList>
  <Row>
   <Value><SimpleValue>AF</SimpleValue></Value>
   <Value><SimpleValue>AFGHANISTAN</SimpleValue></Value>
  </Row>
  <Row>
   <Value><SimpleValue>ZM</SimpleValue></Value>
   <Value><SimpleValue>ZAMBIA</SimpleValue></Value>
  </Row>
 </SimpleCodeList>
</gcl:CodeList>

Appendix 4. Sample UBL code list Schema

The following is an abbreviated version of the UBL country code Schema. All but two of the country codes have been removed, for brevity. Also, please be aware that it has been wrapped to fit with a 75 character width limit, and will not be valid without slight reformatting.

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Universal Business Language (UBL) Schema 1.0

  Copyright (C) OASIS Open (2004). All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it or
  assist in its implementation may be prepared, copied, published and
  distributed, in whole or in part, without restriction of any kind,
  provided that the above copyright notice and this paragraph are included
  on all such copies and derivative works.
  However, this document itself may not be modified in any way, such as by
  removing the copyright notice or references to OASIS, except as needed
  for the purpose of developing OASIS specifications, in which case the
  procedures for copyrights defined in the OASIS Intellectual Property
  Rights document must be followed, or as required to translate it into
  languages other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by OASIS or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  =========================================================================

  For our absent friend, Michael J. Adcock  - il miglior fabbro
  =========================================================================

  Universal Business Language Specification
      (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl)
  OASIS Open (http://www.oasis-open.org/)


  Document Type:     CountryIdentificationCode
  Generated On:      Mon Aug 16 14:34:34 2004
-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0"
    xmlns:ccts="
urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0"
    targetNamespace="
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
    version="1.0">
  <xsd:import
    namespace="
urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0"
    schemaLocation="../common/UBL-CoreComponentParameters-1.0.xsd"/>
  <xsd:simpleType name="CountryIdentificationCodeContentType">
    <xsd:restriction base="xsd:normalizedString">
      <xsd:enumeration value="AD">
        <xsd:annotation>
          <xsd:documentation>
            <CodeName>ANDORRA</CodeName>
          </xsd:documentation>
        </xsd:annotation>
      </xsd:enumeration>
      <xsd:enumeration value="ZW">
        <xsd:annotation>
          <xsd:documentation>
            <CodeName>ZIMBABWE</CodeName>
          </xsd:documentation>
        </xsd:annotation>
      </xsd:enumeration>
    </xsd:restriction>
  </xsd:simpleType>
  <xsd:complexType name="CountryIdentificationCodeType">
    <xsd:annotation>
      <xsd:documentation>
        <ccts:Component>
          <ccts:ComponentType>DT</ccts:ComponentType>
          <ccts:DictionaryEntryName>
Country Identification_ Code. Type
          </ccts:DictionaryEntryName>
          <ccts:RepresentationTerm>Code</ccts:RepresentationTerm>
          <ccts:DataTypeQualifier>
Country Identification
          </ccts:DataTypeQualifier>
          <ccts:DataType>Code. Type</ccts:DataType>
        </ccts:Component>
        <ccts:Instance>
          <ccts:CodeListID>ISO3166-1</ccts:CodeListID>
          <ccts:CodeListAgencyID>6</ccts:CodeListAgencyID>
          <ccts:CodeListAgencyName>
United Nations Economic Commission for Europe
          </ccts:CodeListAgencyName>
          <ccts:CodeListName>Country</ccts:CodeListName>
          <ccts:CodeListVersionID>0.3</ccts:CodeListVersionID>
          <ccts:CodeListURI>
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/li
st-en1-semic.txt
          </ccts:CodeListURI>
          <ccts:CodeListSchemeURI>
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0
          </ccts:CodeListSchemeURI>
          <ccts:LanguageID>en</ccts:LanguageID>
        </ccts:Instance>
      </xsd:documentation>
    </xsd:annotation>
    <xsd:simpleContent>
      <xsd:extension base="CountryIdentificationCodeContentType">
        <xsd:attribute
          name="codeListID" type="xsd:normalizedString" fixed="ISO3166-1"
          use="optional"/>
        <xsd:attribute
          name="codeListAgencyID" type="xsd:normalizedString" fixed="6"
          use="optional"/>
        <xsd:attribute
          name="codeListAgencyName" type="xsd:string"
          fixed="United Nations Economic Commission for Europe"
          use="optional"/>
        <xsd:attribute
          name="codeListName" type="xsd:string" fixed="Country"
          use="optional"/>
        <xsd:attribute
          name="codeListVersionID" type="xsd:normalizedString" fixed="0.3"
          use="optional"/>
        <xsd:attribute name="name" type="xsd:string" use="optional"/>
        <xsd:attribute
          name="languageID" type="xsd:language" fixed="en" use="optional"/>
        <xsd:attribute
          name="codeListURI" type="xsd:anyURI"
          fixed="
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/li
st-en1-semic.txt
"
          use="optional"/>
        <xsd:attribute
          name="codeListSchemeURI" type="xsd:anyURI"
          fixed="
urn:oasis:names:specification:ubl:schema:xsd:CountryIdentificationCode-1.0
"
          use="optional"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:schema>

Appendix 5. Code list and column set WXS Schema

Please be aware that this WXS Schema has been wrapped to fit with a 75 character width limit, and will not be valid without slight reformatting.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://xml.genericode.org/2004/ns/CodeList/0.2/"
  targetNamespace="http://xml.genericode.org/2004/ns/CodeList/0.2/">
 <xsd:complexType name="AnyOtherContent">
  <xsd:annotation>
   <xsd:documentation>Container for any XML content which is in a
    different namespace to the Schema's target
    namespace.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:any namespace="##other" minOccurs="0"
     maxOccurs="unbounded" processContents="lax"/>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="ColumnSetDocument">
  <xsd:annotation>
   <xsd:documentation>Document type for the definition of a column set,
    which is a set of code list columns and/or keys.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:group ref="DocumentHeader">
    <xsd:annotation>
     <xsd:documentation>General document information for the
      column set.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:group ref="ColumnSetContent">
    <xsd:annotation>
     <xsd:documentation>Details of the column set.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
  <xsd:attributeGroup ref="DefaultDatatypeLibrary">
   <xsd:annotation>
    <xsd:documentation>Identification of the default datatype library
     for the column set.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:element name="ColumnSet" type="ColumnSetDocument">
  <xsd:annotation>
   <xsd:documentation>Top-level element for the definition of a
    column set.</xsd:documentation>
  </xsd:annotation>
 </xsd:element>
 <xsd:complexType name="CodeListDocument">
  <xsd:annotation>
   <xsd:documentation>Document type for the definition of a simple or
    derived code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:group ref="DocumentHeader">
    <xsd:annotation>
     <xsd:documentation>General document information for the
      code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:group ref="ColumnSetChoice">
    <xsd:annotation>
     <xsd:documentation>A choice between a column set definition and a
      column set reference.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:group ref="OuterCodeListChoice">
    <xsd:annotation>
     <xsd:documentation>A choice between a simple code list definition
      and a derived code list definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:element name="CodeList" type="CodeListDocument">
  <xsd:annotation>
   <xsd:documentation>Top-level element for the definition of a
    code list.</xsd:documentation>
  </xsd:annotation>
 </xsd:element>
 <xsd:complexType name="CodeListSetDocument">
  <xsd:annotation>
   <xsd:documentation>Document type for the definition of a set of
    code lists.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:group ref="DocumentHeader">
    <xsd:annotation>
     <xsd:documentation>General document information for the
      code list set.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:element name="CodeListRef" minOccurs="0"
     maxOccurs="unbounded" type="CodeListRef"/>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:element name="CodeListSet" type="CodeListSetDocument">
  <xsd:annotation>
   <xsd:documentation>Top-level element for the definition of a
    code list set</xsd:documentation>
  </xsd:annotation>
 </xsd:element>
 <xsd:complexType name="Identification">
  <xsd:annotation>
   <xsd:documentation>Identification and location information for a
    resource.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:group ref="NameSet">
    <xsd:annotation>
     <xsd:documentation>Name(s) for the resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:element name="Version" type="xsd:token">
    <xsd:annotation>
     <xsd:documentation>Version of the resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="CanonicalUri" type="xsd:anyURI">
    <xsd:annotation>
     <xsd:documentation>Canonical URI which serves as a
      unique identifier for all versions of the
       resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="IdentificationUriSet">
    <xsd:annotation>
     <xsd:documentation>Identification and location URIs for the
      resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="Annotation">
  <xsd:annotation>
   <xsd:documentation>User annotation information for a
    resource.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Description" minOccurs="0" type="AnyOtherContent">
    <xsd:annotation>
     <xsd:documentation>Human-readable information about the
      resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="AppInfo" minOccurs="0" type="AnyOtherContent">
    <xsd:annotation>
     <xsd:documentation>Machine-readable information about the
      resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:group name="DocumentHeader">
  <xsd:annotation>
   <xsd:documentation>General document information.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation information for the
      document.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Identification" type="Identification">
    <xsd:annotation>
     <xsd:documentation>Identification and location information for the
      resource defined by the document.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:group>
 <xsd:group name="ColumnSetContent">
  <xsd:annotation>
   <xsd:documentation>Specific details of a column set.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:group ref="ColumnChoice" minOccurs="0" maxOccurs="unbounded">
    <xsd:annotation>
     <xsd:documentation>A choice between a column definition and a
      column reference.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:group ref="KeyChoice" minOccurs="0" maxOccurs="unbounded">
    <xsd:annotation>
     <xsd:documentation>A choice between a key definition and a
      key reference.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:group>
 <xsd:group name="ColumnChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a column definition and a
    column reference.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="Column" type="Column">
    <xsd:annotation>
     <xsd:documentation>Definition of a column.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ColumnRef" type="ColumnRef">
    <xsd:annotation>
     <xsd:documentation>Reference to a column defined in an
      external column set or code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:group name="KeyChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a key definition and a
    key reference.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="Key" type="Key">
    <xsd:annotation>
     <xsd:documentation>Definition of a key.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="KeyRef" type="KeyRef">
    <xsd:annotation>
     <xsd:documentation>Reference to a key defined in an
      external column set or code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:complexType name="Column">
  <xsd:annotation>
   <xsd:documentation>Definition of a column.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User information about the
      column.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="NameSet">
    <xsd:annotation>
     <xsd:documentation>Name(s) of the column.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:element name="Data" type="Data">
    <xsd:annotation>
     <xsd:documentation>Data type of the column.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
  <xsd:attributeGroup ref="IdDefinition">
   <xsd:annotation>
    <xsd:documentation>ID which identifies the column within the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
  <xsd:attributeGroup ref="UseDefinition">
   <xsd:annotation>
    <xsd:documentation>Whether the column is required or
     optional.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:complexType name="ColumnRef">
  <xsd:annotation>
   <xsd:documentation>Reference to a column defined in an
    external column set or code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      referenced column.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="IdentificationUriSet">
    <xsd:annotation>
     <xsd:documentation>Identification of the external column set or
      code list which contains the column definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
  <xsd:attributeGroup ref="IdDefinition">
   <xsd:annotation>
    <xsd:documentation>ID which identifies the column within the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
  <xsd:attributeGroup ref="ExternalReference">
   <xsd:annotation>
    <xsd:documentation>ID which identifies which identifies the
     column within the external column set or
     code list.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
  <xsd:attributeGroup ref="UseDefinition">
   <xsd:annotation>
    <xsd:documentation>Whether the column is required or
     optional.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:complexType name="Key">
  <xsd:annotation>
   <xsd:documentation>Definition of a key.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the key.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="NameSet">
    <xsd:annotation>
     <xsd:documentation>Name(s) of the key.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:element name="ColumnRef" maxOccurs="unbounded" type="KeyColumnRef">
    <xsd:annotation>
     <xsd:documentation>References to the document IDs of the
      columns which make up the key.  Only required columns can form
      part of a key.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
  <xsd:attributeGroup ref="IdDefinition">
   <xsd:annotation>
    <xsd:documentation>ID which identifies the key within the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:complexType name="KeyRef">
  <xsd:annotation>
   <xsd:documentation>Reference to a key defined in an
    external column set or code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      referenced key.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="IdentificationUriSet">
    <xsd:annotation>
     <xsd:documentation>Identification of the external column set or
      code list which contains the key definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
  <xsd:attributeGroup ref="IdDefinition">
   <xsd:annotation>
    <xsd:documentation>ID which identifies the key within the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
  <xsd:attributeGroup ref="ExternalReference">
   <xsd:annotation>
    <xsd:documentation>ID which identifies which identifies the
     key within the external column set or code list.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:group name="ColumnSetChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a column set definition and a
    column set reference.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="ColumnSet" type="ColumnSet">
    <xsd:annotation>
     <xsd:documentation>Definition of a column set.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ColumnSetRef" type="ColumnSetRef">
    <xsd:annotation>
     <xsd:documentation>Reference to a column set defined in an
      external column set or code list document.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:complexType name="ColumnSet">
  <xsd:annotation>
   <xsd:documentation>Definition of a column set.</xsd:documentation>
  </xsd:annotation>
  <xsd:group ref="ColumnSetContent">
   <xsd:annotation>
    <xsd:documentation>Details of the column set.</xsd:documentation>
   </xsd:annotation>
  </xsd:group>
  <xsd:attributeGroup ref="DefaultDatatypeLibrary">
   <xsd:annotation>
    <xsd:documentation>Identification of the default datatype library
     for the column set.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:complexType name="ColumnSetRef">
  <xsd:annotation>
   <xsd:documentation>Reference to a column set defined in an
    external column set or code list document.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      referenced column set.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="IdentificationUriSet">
    <xsd:annotation>
     <xsd:documentation>Identification of the external column set or
      code list document which contains the column set
      definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:group name="OuterCodeListChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a simple code list definition and a
    derived code list definition.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:group ref="SimpleCodeListSequence">
    <xsd:annotation>
     <xsd:documentation>Details of a simple code list
      definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
   <xsd:element name="DerivedCodeList" type="DerivedCodeList">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      derived code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:complexType name="SimpleCodeList">
  <xsd:annotation>
   <xsd:documentation>Definition of a
    simple code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation for the
      code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Row" minOccurs="0" maxOccurs="unbounded" type="Row">
    <xsd:annotation>
     <xsd:documentation>Row which represents one of the
      conceptual codes in the code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="DerivedCodeList">
  <xsd:annotation>
   <xsd:documentation>Definition of a
    derived code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation for the
      code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="DerivedCodeListChoice">
    <xsd:annotation>
     <xsd:documentation>A choice of one of the different types of
      derived code list definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:group name="IdentificationUriSet">
  <xsd:annotation>
   <xsd:documentation>Identification and location URIs for a
    resource.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="CanonicalVersionUri" type="xsd:anyURI">
    <xsd:annotation>
     <xsd:documentation>Canonical URI which serves as a unique identifier
      for this version of the resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="LocationUri" minOccurs="0"
     maxOccurs="unbounded" type="xsd:anyURI">
    <xsd:annotation>
     <xsd:documentation>Suggested retrieval location for this version
      of the resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:group>
 <xsd:complexType name="CodeListRef">
  <xsd:annotation>
   <xsd:documentation>Reference to a code list defined in an
    external document.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      referenced code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="IdentificationUriSet">
    <xsd:annotation>
     <xsd:documentation>Identification of the external document which
      contains the code list definition.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:group name="InnerCodeListChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a simple code list definition,
    a derived code list definition, or a reference to a code list
    defined in an external document.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="SimpleCodeList" type="SimpleCodeList">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      simple code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="DerivedCodeList" type="DerivedCodeList">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      derived code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="CodeListRef" type="CodeListRef">
    <xsd:annotation>
     <xsd:documentation>Reference to a code list defined in an
      external document.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:attributeGroup name="IdDefinition">
  <xsd:annotation>
   <xsd:documentation>Attribute set used to identify a resource within
    the document.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="Id" type="xsd:ID" use="required">
   <xsd:annotation>
    <xsd:documentation>Unique ID within the document for the
     resource.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:attributeGroup>
 <xsd:attributeGroup name="ExternalReference">
  <xsd:annotation>
   <xsd:documentation>Attribute set used to identify a resource within
    an external document.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="ExternalRef" type="xsd:token" use="required">
   <xsd:annotation>
    <xsd:documentation>Unique ID of the resource within the
     external document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:attributeGroup>
 <xsd:group name="NameSet">
  <xsd:annotation>
   <xsd:documentation>Name(s) for a resource.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="ShortName" type="xsd:token">
    <xsd:annotation>
     <xsd:documentation>Short name (token) for the
      resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="LongName" minOccurs="0"
     maxOccurs="unbounded" type="xsd:normalizedString">
    <xsd:annotation>
     <xsd:documentation>Long name for the resource.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:group>
 <xsd:complexType name="Data">
  <xsd:annotation>
   <xsd:documentation>Data type for a column.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation for the
      datatype.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Parameter" minOccurs="0"
     maxOccurs="unbounded" type="DatatypeFacet">
    <xsd:annotation>
     <xsd:documentation>Facet parameter which refines the
      datatype.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
  <xsd:attribute name="Type" type="xsd:token" use="required">
   <xsd:annotation>
    <xsd:documentation>Unique ID for the datatype within its
     datatype library.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
  <xsd:attribute name="DatatypeLibrary" type="xsd:anyURI">
   <xsd:annotation>
    <xsd:documentation>URI which uniquely identifies the datatype library.
     If not provided, the datatype library for the enclosing column set
     is used.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:complexType>
 <xsd:complexType name="KeyColumnRef">
  <xsd:annotation>
   <xsd:documentation>Reference to a column which forms part of a
    key.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" form="unqualified">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      column.</xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
     <xsd:annotation>
      <xsd:documentation>User annotation information for a
       resource.</xsd:documentation>
     </xsd:annotation>
     <xsd:sequence>
      <xsd:element name="Description" minOccurs="0" form="unqualified">
       <xsd:complexType>
        <xsd:annotation>
         <xsd:documentation>Human readable information about the
          resource.</xsd:documentation>
        </xsd:annotation>
       </xsd:complexType>
      </xsd:element>
      <xsd:element name="AppInfo" minOccurs="0" form="unqualified">
       <xsd:complexType>
        <xsd:annotation>
         <xsd:documentation>Machine-readable information about the
          resource.</xsd:documentation>
        </xsd:annotation>
       </xsd:complexType>
      </xsd:element>
     </xsd:sequence>
    </xsd:complexType>
   </xsd:element>
  </xsd:sequence>
  <xsd:attribute name="Ref" type="xsd:IDREF" use="required">
   <xsd:annotation>
    <xsd:documentation>Reference to the ID of the column within the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:complexType>
 <xsd:group name="SimpleCodeListSequence">
  <xsd:annotation>
   <xsd:documentation>Details of a
    simple code list definition.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="DerivedCodeListRef" minOccurs="0" type="CodeListRef">
    <xsd:annotation>
     <xsd:documentation>Reference to the derived code list of which this
      simple code list is a realisation.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="SimpleCodeList" type="SimpleCodeList">
    <xsd:annotation>
     <xsd:documentation>Definition of the
      simple code list.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:group>
 <xsd:attributeGroup name="UseDefinition">
  <xsd:annotation>
   <xsd:documentation>Attribute set which defines the usage of a
    resource.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="Use" type="UseType" use="required">
   <xsd:annotation>
    <xsd:documentation>Whether the resource is required or
     optional.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:attributeGroup>
 <xsd:complexType name="Row">
  <xsd:annotation>
   <xsd:documentation>Row which represents a conceptual code in a
    code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the row.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Value" maxOccurs="unbounded" type="Value">
    <xsd:annotation>
     <xsd:documentation>Column value for the row.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:group name="ValueChoice">
  <xsd:annotation>
   <xsd:documentation>A choice between a simple textual value and a
    complex (structured) XML value.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="SimpleValue" type="SimpleValue">
    <xsd:annotation>
     <xsd:documentation>Simple textual value.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ComplexValue" type="AnyOtherContent">
    <xsd:annotation>
     <xsd:documentation>Complex (structured) XML value.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:complexType name="SimpleValue">
  <xsd:annotation>
   <xsd:documentation>Simple textual value.</xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
   <xsd:extension base="xsd:string"/>
  </xsd:simpleContent>
 </xsd:complexType>
 <xsd:attributeGroup name="ColumnReference">
  <xsd:annotation>
   <xsd:documentation>Attribute set for referring to a
    column definition within the document.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="ColumnRef" type="xsd:IDREF">
   <xsd:annotation>
    <xsd:documentation>Reference to the ID of a column in the
     document.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:attributeGroup>
 <xsd:complexType name="Value">
  <xsd:annotation>
   <xsd:documentation>Individual value from a row which represents a
    conceptual value in a code list.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      value.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:group ref="ValueChoice">
    <xsd:annotation>
     <xsd:documentation>A choice between a simple textual value and a
      complex (structured) XML value.</xsd:documentation>
    </xsd:annotation>
   </xsd:group>
  </xsd:sequence>
  <xsd:attributeGroup ref="ColumnReference">
   <xsd:annotation>
    <xsd:documentation>Reference to the column with which this value is
     associated.  If not provided, the column is assumed to be the
     column following the column of the
     preceding value.</xsd:documentation>
   </xsd:annotation>
  </xsd:attributeGroup>
 </xsd:complexType>
 <xsd:group name="DerivedCodeListChoice">
  <xsd:annotation>
   <xsd:documentation>A choice of one of the different types of
    derived code list definition.</xsd:documentation>
  </xsd:annotation>
  <xsd:choice>
   <xsd:element name="ColumnSetExclusion" type="ColumnSetFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      column set exclusion filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ColumnSetInclusion" type="ColumnSetFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      column set inclusion filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ColumnSetMatch" type="ColumnSetFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      column set match filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="ColumnSetUnion" type="CodeListUnion">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      column set union filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="RowExclusion" type="RowFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      row exclusion filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="RowInclusion" type="RowFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      row inclusion filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="RowMatch" type="RowFilter">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      row match filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="RowUnion" type="CodeListUnion">
    <xsd:annotation>
     <xsd:documentation>Definition of a
      row union filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:choice>
 </xsd:group>
 <xsd:complexType name="RowFilter">
  <xsd:annotation>
   <xsd:documentation>Definition of a row filter.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation for the
      row filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Source" type="InputCodeList">
    <xsd:annotation>
     <xsd:documentation>Source code list for the
      row filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Control" type="InputCodeList">
    <xsd:annotation>
     <xsd:documentation>Control code list for the
      row filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="InputCodeList">
  <xsd:annotation>
   <xsd:documentation>Input code list for a code list filter or
    union.</xsd:documentation>
  </xsd:annotation>
  <xsd:group ref="InnerCodeListChoice">
   <xsd:annotation>
    <xsd:documentation>A choice between a simple code list definition,
     a derived code list definition, or a reference to a code list
     defined in an external document.</xsd:documentation>
   </xsd:annotation>
  </xsd:group>
 </xsd:complexType>
 <xsd:complexType name="CodeListUnion">
  <xsd:annotation>
   <xsd:documentation>Union of one or more code lists.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the
      union.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Source" maxOccurs="unbounded" type="InputCodeList">
    <xsd:annotation>
     <xsd:documentation>Source code list for the union.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="ColumnSetFilter">
  <xsd:annotation>
   <xsd:documentation>Definition of a column set
    filter.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
   <xsd:element name="Annotation" minOccurs="0" type="Annotation">
    <xsd:annotation>
     <xsd:documentation>User annotation about the column set
      filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Source" type="InputCodeList">
    <xsd:annotation>
     <xsd:documentation>Source code list for the column set
      filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
   <xsd:element name="Control" type="InputColumnSet">
    <xsd:annotation>
     <xsd:documentation>Control column set for the column set
      filter.</xsd:documentation>
    </xsd:annotation>
   </xsd:element>
  </xsd:sequence>
 </xsd:complexType>
 <xsd:complexType name="InputColumnSet">
  <xsd:annotation>
   <xsd:documentation>Input column set for a code list
    filter.</xsd:documentation>
  </xsd:annotation>
  <xsd:group ref="ColumnSetChoice">
   <xsd:annotation>
    <xsd:documentation>A choice between a column set definition and a
     column set reference.</xsd:documentation>
   </xsd:annotation>
  </xsd:group>
 </xsd:complexType>
 <xsd:complexType name="DatatypeFacet">
  <xsd:annotation>
   <xsd:documentation>Facet information for refining a
    datatype.</xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
   <xsd:extension base="xsd:string">
    <xsd:attribute name="ShortName" type="xsd:token" use="required">
     <xsd:annotation>
      <xsd:documentation>Short name (token) for the
       datatype facet.</xsd:documentation>
     </xsd:annotation>
    </xsd:attribute>
    <xsd:attribute name="LongName" type="xsd:normalizedString">
     <xsd:annotation>
      <xsd:documentation>Long name for the
       datatype facet.</xsd:documentation>
     </xsd:annotation>
    </xsd:attribute>
   </xsd:extension>
  </xsd:simpleContent>
 </xsd:complexType>
 <xsd:attributeGroup name="DefaultDatatypeLibrary">
  <xsd:annotation>
   <xsd:documentation>Identification of the default datatype library
    for a column set.</xsd:documentation>
  </xsd:annotation>
  <xsd:attribute name="DatatypeLibrary" type="xsd:anyURI"
   default="http://www.w3.org/2001/XMLSchema-datatypes">
   <xsd:annotation>
    <xsd:documentation>URI which uniquely identifies the
     default datatype library for the column set.  If not provided,
     defaults to the URI for W3C XML Schema datatypes.</xsd:documentation>
   </xsd:annotation>
  </xsd:attribute>
 </xsd:attributeGroup>
 <xsd:simpleType name="UseType">
  <xsd:annotation>
   <xsd:documentation>Indicates whether the usage of a resource is required
    or optional.</xsd:documentation>
  </xsd:annotation>
  <xsd:restriction base="xsd:token">
   <xsd:enumeration value="optional"/>
   <xsd:enumeration value="required"/>
  </xsd:restriction>
 </xsd:simpleType>
</xsd:schema>

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.

Why are simple code lists so complex?

Abstract

Table of Contents