While XML Schema covers the logical aspects of document type definitions, it does not prescribe how to define the physical aspects. Many XML processors require extra information on how to process the instances of a given document class. Tamino, for example, needs to know the collection to which a document class belongs, the elements or attributes which are used for indexing, the type of indexing that is used, how document elements may be mapped onto fields in external databases, and so on.
For these and other purposes XML Schema provides an extension mechanism.
Any schema, element or attribute definition in XML Schema can be equipped with
one or more annotations. Each annotation can consist of two child
elements: documentation and appinfo. The
documentation element contains documentation for human readers,
and the appinfo element contains information for machines.
Tamino uses the appinfo element
to store Tamino-related information within a schema
file:
<?xml version = "1.0" encoding = "UTF-8"?>
<xs:schema
xmlns = "http://www.softwareag.com/tamino/doc/examples/models/jazz/encyclopedia"
xmlns:xs = "http://www.w3.org/2001/XMLSchema"
xmlns:tsd = "http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition"
targetNamespace = "http://www.softwareag.com/tamino/doc/examples/models/jazz/encyclopedia"
elementFormDefault = "qualified"
>
<xs:annotation>
<xs:appinfo>
<tsd:schemaInfo name = "albumSchema">
<tsd:collection name = "encyclopedia"/>
<tsd:doctype name = "album">
<tsd:logical>
<tsd:content>open</tsd:content>
<tsd:accessOptions>
<tsd:read/>
<tsd:insert/>
<tsd:delete/>
<tsd:update/>
</tsd:accessOptions>
</tsd:logical>
</tsd:doctype>
</tsd:schemaInfo>
</xs:appinfo>
</xs:annotation>
...
</xs:schema>
These annotations are generated by the Tamino Schema Editor.
The example above shows an annotation on the schema level. This is
indicated by the <tsd:schemaInfo> element. The attribute
name specifies the name of the schema
(albumSchema).
Enclosed in the <tsd:schemaInfo> element is a
definition for the Tamino collection to which the
schema belongs. Typically a collection contains document types that are somehow
related, for example the document types derived from a specific conceptual
model or all schemas that belong to a given application.
Here, we define a collection encyclopedia that will
eventually contain all the document types (jazzMusician,
style, collaboration, album,
review and critic) that we defined earlier (From
Conceptual Model to Schema::From Model to
Schema).
In addition to the <tsd:collection> element, the
element <tsd:schemaInfo> contains a
<tsd:doctype> element which defines the name of the document
type as album. This name is not necessarily the same as the schema
name, but must match the root element name of each document instance belonging
to that particular document type.
The <tsd:doctype> element may contain an element
<tsd:logical>. This element specifies the access options for
the document instances and the content type:
The access options specify the database operations (read, insert, update, delete) that are allowed for this document type;
The content type "closed" specifies that a document instance may not contain deeper structures than specified in the schema. In contrast, content type "open" allows document instances to be extended with tags that are not defined in the schema.
This is a more flexible - albeit non-standard - approach to the open
content model than using xs:any and xs:anyAttribute.
For a discussion of the pros and cons of the
Tamino-specific open content model, see also
Tamino-specific Extensions
to Logical Schema::Open Content vs. Closed Content
Validation.
We could, for example, define our style document type with
content type "open" because its
description element may contain other markup. However, using an
xs:any child node for the description element
definition is probably the better choice here: thus we stay with the W3C XML
Schema recommendation, and we are able to specify a namespace for the XHTML
content of the description element.
The physical properties of each document node can be specified with
similar annotations. Again, these annotations are generated by the
Tamino Schema Editor. Here is an example for the
attribute ID of our schema jazzMusician:
and the resulting code:
<xs:attribute name = "ID" type = "xs:NMTOKEN" use = "required" form = "unqualified">
<xs:annotation>
<xs:appinfo>
<tsd:attributeInfo>
<tsd:physical>
<tsd:native>
<tsd:index>
<tsd:standard></tsd:standard>
</tsd:index>
</tsd:native>
</tsd:physical>
</tsd:attributeInfo>
</xs:appinfo>
</xs:annotation>
Contained in the <xs:appinfo> element is the element
<tsd:attributeInfo>, which describes the properties of this
attribute node. In the Tamino Schema Editor we have
specified that the storage type of the attribute is
"Native". This means that the attribute is to be
stored as native XML in Tamino. There are also other
options, for example, to map a document node to a
Tamino Server Extension (see
Utilizing
Server Extensions::Derived
elements) or to fields in a foreign database such as Adabas or
a third-party RDBMS.