Summary information on the SDD Schema

(Version: SDD 0.9.030, 1. Dec. 2003)

TDWG working group: Structure of Descriptive Data (SDD)

The standard schema reports generated by xml spy or the xs3p script document the structure of the schema organized by the element and type tree. As a supplement to this, this report documents the use of selected features throughout the entire schema.

This is a highly technical report aimed at xml schema experts. The purpose of the type and element listing is primarily to search for design problems or errors in the schema. The overview over default values and identity constraints is valuable for implementers.

See the "Overview of available documentation" for further information.

Table of contents

1. Type inheritance
   • Complex types derived by extension
   • Complex types derived by restriction
   • Simple types derived by restriction
2. Type usage
   • Usage of complex types
   • Usage of simple types
3. Table of elements (names and types)
4. Table of defined default values
5. Identity constraints
   • Key identity constraints
   • Keyref identity constraints
   • Uniqueness constraints
6. Separate file: Table of annotations containing the problem marker (= '@')

Type inheritance

The SDD schema is used object-oriented inheritance mechanisms for complex types. The following tables give an overview of type derivations present in the schema.

Complex types derived by extension

(Indirectly derived types are currently not listed)

Complex types derived by restriction

Simple types derived by restriction

Type usage

The following tables provide an overview of the number of times complex and simple types are used in the schema. Only schema-specific types are reported, not the w3c defined base types (xs:string, xs:boolean, etc.). Type usage is interesting to detect orphan (unused) types, or to argue whether types used only a single time should rather be anonymous.

Usage of complex types

Usage of simple types

Table of elements (names and types)

The SDD schema uses element names with different types, depending on the context. To write xslt it is often useful to know which element names in a schema uniquely refer to a type, and which depend on the context. The following list shows all elements in alphabetical order together with their type name. Anonymous types, including type derivations, cannot be shown (an advanced script would be able to list the base type of a derivation, but in most cases we avoid anonymous derivation in SDD so we did not implement this in the report).

The use of an element name with several different types has two major sources: a) the alternative element types are themselves all derived from a base type (see e. g. Modifiers), or b) an object is defined in one place and a reference is made to it. This is very similar to the usage pattern in xml schema itself, where object names are used both for definition and reference (examples: element name="x" and element ref="x", or group name="y" and group ref="y").

Table of defined default values

Elements or attributes for which default values have been defined in the schema need special attention insofar as the processing of an instance document depends on whether it has been validated against the schema (validation will add default values in the infoset). A script or application processing instance documents may thus either validate the document, or it may handle the following attributes itself.

Identity constraints

Key identity constraints

The SDD schema is an object-relational design where data structures cannot be shown in a single hierarchical tree. It therefore makes liberal use of key/keyref relations. The integrity of these relations is protected by two xml schema mechanisms: xs:key guarantees that all key values are present and unique, and xs:keyref guarantees that all references to key values point to an existing key. The following tables give an overview of the key and keyref constraints defined in the schema:

Keyref identity constraints

Uniqueness constraints

Uniqueness constraints differ from key constraints in that the elements referred to are not required to be present. However, whenever they are present, however, the combination of all fields has to be unique. In SDD schema, most uniqueness constraints could in fact be modeled as key constraints, since the data elements are required. However, to stress the distinction between key definitions to which keyrefs refer, and other constraints, we prefer to model them as uniqueness constraints.

(Generated on 3. Dec. 2003 by DiversitySchemaTools Version 0.2. Copyright (c) G. Hagedorn 2003.)