STMML is an XML-based markup language covering many generic aspects of scientific information. It has been developed as a re-usable core for more specific markup languages. It supports data structures, data types, metadata, scientific units and some basic components of scientific narrative. The central means of adding semantic information is through dictionaries. The specification is through an XML Schema which can be used to validate STMML documents or fragments. Many examples of the language are given.
Keywords: Extensible-markup-language (XML), Chemical-markup-language (CML), Extensible-stylesheet-language-transformations (XSLT), XMLSchema, Semantic-Web, Scientific-Technical-Medical (STM), Scientific Units, Metadata, Data Types, Data Structures, Dictionaries, Terminology.
Currently most Scientific-Technical-Medical (STM) publications are printed on paper and aimed at human readers. Where electronic versions occur, most are created as "e-paper", i.e. for ultimate viewing and interpretation by humans. The technologies for this, primarily HTML and PDF along with proprietary document formats, do not support machine processing. For example machines cannot easily extract meaningful data from these documents; they are normally limited to textual searches without a knowledge of the context in which the text occurs.
We have reviewed the need for machine-processing in an earlier article (Murray-Rust & Rzepa, 2002a). In this we argued that XML (eXtensible Markup Language) is a radical development in STM publishing, and that a "datument" (a portmanteau neologism of document+data) could be created from a number of carefully constructed information components. Each basic component is supported by a markup language (ML). For example we have developed a language termed Chemical Markup Language or CML (Murray-Rust & Rzepa, 1999; Murray-Rust & Rzepa, 2001) to manage chemical information, especially molecules. Similar markup languages (e.g. CellML, MathML, Geographical Markup Language, Reaction XML, and many more) are being developed in many STM domains (Cover, 2002). These languages are developed by a core of collaborating specialists and provide specific vocabularies for their disciplines. Normally there is a need to create specific software tools (e.g. for graphical input and display of molecules, maps, mice, etc). Thus considerable effort is required and such languages need careful design and management. A likely outcome is that these will become 'standard' (at least de facto) and will form the core method of deposition of specialist data with publishers and archivists.
However there is a large communality in the core and infrastructure of these languages, such as numbers, scientific units, metadata, simple data structures, etc. Building the required tools for this is not trivial and there is a great danger in "reinventing the wheel". Chemistry requires much of this infrastructure and we have had to implement software systems for managing basic scientific data. Our efforts have resulted in a generic approach which can be valuable as an existing infrastructure for most STM domains to build on. In this article we offer this generic core for use by the STM community as a starting point or re-usable component for their own domain. An additional benefit would be that less software needs to be developed and this may make it easier for publishers to implement systems and accept markup-language-based datuments.
In this article we assume some familiarity with basic XML (World Wide Web Consortium, n.d.) and its terminology such as element and attribute. and the syntax for these:
<anElement attribute1="value1" attribute2="value2"> <childElement>Some text content</childElement> <anEmptyElement attribute3="value3"/> </anElement>
We shall review in more detail the concepts behind XML namespaces and the recent XML Schema specification. Other XML protocols and tools which are likely to occur in generic XML applications are:
When designing CML 1.0 (Murray-Rust & Rzepa, 1999; Murray-Rust & Rzepa, 2001; Gkoutos, Murray-Rust, Rzepa & Wright (2001b) we found that many components with a "chemical content" did not require chemical concepts for their implementation. Thus the "melting point of a substance" is a numeric quantity, with error estimates and scientific units, and a name (or term) representing the concept. There is nothing specifically chemical in the abstraction of the information; the same technology could represent "rectal temperature of patient". To add the semantics (e.g. "a melting point is the temperature at which a solid turns to liquid") requires a generic mechanism - in our case through a specialised dictionary. We therefore had to include generic STM concepts in CML when it was first developed (Murray-Rust, Leach & Rzepa, 1995). XML technology has now developed to allow combination of modular components and we have therefore modularised CML 1.0 into two parts; the purely chemical core components e.g. representation of molecules, which becomes CMLCore (Murray-Rust & Rzepa, 2002b) and the general STM infrastructure which here is described as STMML 1.0. Since STMML is general, we offer it to the STM community as a tool for any scientific domain.
Because of the ubiquity and fundamental nature of the problem we are addressing - the description of general STM information - the community is likely to develop several (possibly independent) approaches. Although there are several groups who are addressing this problem through markup languages, we are unaware of any formally published and tested specifications.
There are also languages which address general modelling of systems, some impressive ones being:
These cover some of the same concepts as STMML (e.g. units, metadata). They are generally at a higher level of abstraction than provided by STMML. Thus CellML has elements such as group, connection, etc. Like STMML they use a modular approach and will re-use other specifications rather than re-inventing them.
We believe that the use of markup languages will be dynamic and evolve as they fill needs and can be implemented. STMML has been deliberately kept simple and concrete. It has been proven to work in conjunction with CML and is particularly aimed at publishing heterogeneous data. It is deliberately Open, i.e. non-proprietary and aimed inter alia at supporting publication in a context where authors are not necessarily initially familiar with the concepts of markup.
The W3C, when designing XML, produced a set of design criteria which were extremely useful for the developer community. We followed the same principle for CML and do so here for STMML. The primary design considerations are:
From an analysis of a number of STM articles we have derived a set of generic information components, independent of the domain. Some were explicit such as tables while others were implicit such as points on graphs, references to unpublished or supplemental data, etc. Most are amenable to representation in XML and this would allow all data to be included in the published datument. The reader could have access to the whole background of the publication; hopefully enough to reproduce the experiment or to analyse it further with a different set of software tools (Rzepa & Murray-Rust, 2001).
We recognise that many disciplines create very large and complex data sets which are already managed by standards (formal or de facto agreements) and for which authoring and processing software exists. XML has no special support for very large datasets. An example is image data from crystallographic detectors where the IUCr CIF community has created a protocol for interchange (Hall, Allen & Brown, 1991). In other cases protocols such as JCAMP for spectra have their own syntax and some variants are not human-readable. This seriously reduces the interoperability and puts a large burden on the community to write software, without the re-use that XML provides. Recognising this, some domains such as e.g. the genomic community are increasingly using XML for nucleic and protein sequence information. Even if XML is not used for the transport of the data itself, it will be valuable for the metadata, including details on what software should be used to process the data.
Our current analysis is unlikely to be universally applicable. It is only through the discipline of marking up real publications that further useful abstractions occur. The list below is very general; indeed many of the components will occur in business and e-commerce. At present we see a wide need for:
A...(property)...>BThis can represent a complex system of relationships but has no generic mechanism for adding program functionality to the properties. STM authors will need to choose between generic mechanism and developing support for specific relations in their own MLs. STMML introduces a generic element <link> to support mappings.
Namespaces are not formally part of XML V1.0 and were introduced in 1998 (World Wide Web Consortium, n.d.). They have since become universal in all XML-based languages and are supported by XML-tools and APIs such as DOM and SAX. The namespace concept is simple: every element and every attribute in a document can have a unique namespace associated with it. Uniqueness is created through a namespace URI, normally containing the domain name of the "owner" of the vocabulary, though other systems such as the ISBN number could be used. Despite its URI-based syntax the namespaceURI does not have to exist physically and there is no requirement to connect to networks. Note that the namespace prefix is arbitrary; although "xsl" is used below, any unique prefix would suffice.
We have created an example which uses three namespaces. Two represent content (XHTML and CML) and one supports infrastructure (XSLT). There is no limit on the number or purpose of namespaces in a document; we have published an article which uses six (Murray-Rust, Rzepa and Wright, 2001).
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:h="http://www.w3.org/1999/xhtml"
xmlns="http://www.xml-cml.org/schema/cml2/core"
version="1.0">
<xsl:template match="molecule">
<h:h2>Entry ID:<xsl:value-of select="@id"/></h:h2>
</xsl:template>
</xsl:stylesheet>
The three namespaces above are:
There is no requirement to have a default namespace and if elements are always prefixed it may make it easy to merge document components. The namespace allows the processing systems to decide exactly what version of the software to use. At present there is no universal method for automatically associating actual software ( such as through the use of e.g. java class libraries) with a namespace URI but this will certainly become common.
The example above represents part of an XSL stylesheet and shows how information can be transformed from one namespace (CMLCore Schema) to another (XHTML). In the next example we show how different namespaces can be combined to create a composite document:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:cml="http://www.xml-cml.org/schema/cml2/core">
<p>We can supply the following set of molecules:</p>
<ul>
<li>
<cml:molecule id="p1" title="phosphine">
<cml:atomArray>
<cml:atom elementType="P" hydrogenCount="3"/>
</cml:atomArray>
</cml:molecule>
</li>
<li><cml:molecule id="p2" title="penguinone"/></li>
</ul>
</html>
Here the default namespace is XHTML, and elements from another namespace (CMLCore) are contained in HTML elements (li). With XML Schemas and XSLT the components can be separately validated (see below). With DTDs this would be messy and the document probably could not be DTD-validated (the content model for li cannot contain CML elements). Namespaces allow us to regard fragments of the document as architecturally independent, and these fragments can be processed separately.
XPath is the syntax for addressing nodes within XML documents and is used by protocols such as XSLT and XQuery (under development). A namespace prefix in the XPath expression is arbitrary and
<foo xmlns:bar="http://www.xml-cml.org/schema/cml2/core"> <xsl:variable name="mols" select="bar:molecule"/> </foo>
will retrieve molecules from any elements mapped to the CML namespace URI. They do not have to use the prefix cml. Note also that other elements which happen to have the elementName cml:molecule mapped to a different namespace will not be selected, as the next example shows.
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:c="http://www.xml-cml.org/schema/cml2/core"
xmlns:cml="http://www.penguinchem.com/schema">
<p>We can supply the following set of molecules:</p>
<ul>
<li>
<c:molecule id="p1" title="phosphine">
<c:atomArray>
<c:atom elementType="P" hydrogenCount="3"/>
</c:atomArray>
</c:molecule>
</li>
<!-- not a CML molecule -->
<li><cml:molecule foo="p2" bar="penguinone"/></li>
</ul>
</html>
Even though the second molecule has the (rather misleading) prefix cml it does not belong to the CMLCore namespace and will not be retrieved by the XPath expression. This provides a mechanism (if required) for mixing different versions of a markup language (though this should always be done with great caution).
If information can be packaged into modules the benefits are very considerable:
<p:entry id="p123" sku="P-123-4">
<p:price amount="1000" unit="ml">
<p:currency="USD">100</p:currency>
<p:currency="GBP">66</p:currency>
</p:price>
<c:molecule id="p1" title="phosphine" xmlns:c="http://www.xml-cml.org/schema/cml2/core>
<c:atomArray>
<c:atom elementType="P" hydrogenCount="3"/>
</c:atomArray>
</c:molecule>
</p:entry>
Modularization is not always possible. This happens when concepts are not "atomic" - e.g. where A relies on information in B. This is an example of context-dependency, or coupling, and can be very difficult to model. STMML components are not coupled and can be used as independent components in a larger aggregate.
In many cases there are implicit relationships between components, and no simple way of implementing them automatically. Thus when modelling the concept of concentration for CML we found it necessary to create two new elements, substance and substanceList which are now part of CML 2.0 (Murray-Rust and Rzepa, 2002b). Similarly in modelling interatomic angles in molecules there was an implicit assumption that all atoms belonged to a common coordinate system.
Mappings and comparisons are particularly challenging. Thus a "sequence alignment" (e.g. for proteins) is a mapping of 2 or more sequences. A common method is to insert "gaps" into the sequences such as:
ACDEF-GH A-DEFQGH
The gaps, however, are meaningless without the context and could change if other sequences are added. We tackle this by creating a link element, which can express relationships between different information components. Our strategy is based on the XLink specification (World Wide Web Consortium) and depending on the development of generic XLink tools we may increasingly use that symbolism.
It has been estimated that a large proportion of software errors, perhaps up to 50%, arise from "invalid data", i.e. data input that does not conform to the concepts for which the software was written. Non-conformance can be due to data corruption, inputting data for a different (version of the) program, data out of range or otherwise meaningless. There are famous cases (Olken and McCarthy, 2000) where use of the wrong scientific units have been catastrophic. Perhaps the most pernicious is when a user has a different interpretation of the semantics; the data appear valid but are actually inconsistent with the program.
Schema-based Validation goes a long way to solving these problems. Essentially a Schema is a machine processible contract between the program author and the user. The programmer uses the schema to write the program, and we have found it to be a very powerful tool. In fact, for many Schemas useful code can be automatically generated from the schema. If the data can be shown to be valid, then the program should process them reliably. If this does not happen, this is a program error. If the data are invalid, it is the user's responsibility. This separation of responsibilities is far more important than is generally realised and is a major tool in increasing the quality of software.
Validity is a machine-based concept. The more that the human view of validity can be formally encoded, the more useful it becomes. In chemistry for example, is the representation "T" (often written for tritium, an isotope of hydrogen) a valid element Type? (In CMLCore Schema it is not). Software often does not define openly what values are allowed. Using XML Schemas, we can give a precise enumeration of allowed values. Is a negative crystallographic cell angle allowed? Most users and software developers would assume not, but this is not normally checked or disallowed.
XML Schemas allow three main types of validation:
[A-Z]{6}([0-9][0-9])?
specifying six alpha characters followed by two optional
digits (e.g. AABHTZ, ABCDEF01). Note, however,
that XML Schema per se has no support for scientific
units, which is why we use STMML to add them.
STM data requires a range of datatypes, many of them representable by a character string such as "1.234E+05", "Sb", "2001-12-31". In XML V1.0 these cannot be validated, but XML Schema introduces 43 concrete datatypes for <xsd:simpleType>s (Figure 1).
Figure 1. W3C Datatypes (taken from W3C Schema Part II datatypes, World Wide Web Consortium, n.d.).
If a value does not conform, the document is invalid. Among the constraints (some are referred to as facets) are:
It is possible to construct new datatypes derived from XML Schema datatypes. Examples of types defined in STMML are shown in Table 1.
These datatypes are themselves extensible; thus a complex number can be represented by coordinate2 with the addition of a convention attribute to emphasize the semantics. Moreover the enumerated lists in the Schema can be extended to incorporate other values; a user could define additional types of matrices (but would also have to provide the processing semantics).
| Table 1. Datatypes in STMML | ||
|---|---|---|
| type | role | example |
| coordinate2Type | a 2-D Coordinate | 1.2 2.3 |
| coordinate3Type | a 3-D Coordinate | 1.2 2.3 3.4 |
| dataTypeType | data types definable in a dictionary entry | xsd:float |
| delimiterType | delimiters for separating numbers | / |
| errorBasisType | basis of errors | range |
| errorValueType | type of errors | standard error |
| idType | An ID | a123 |
| matrixType | matrix Type | upperTriangular |
| namespaceRefType | namespaced data | core:mpt |
| unitsType | scientific units | units:ml |
XMLSchema constrains the structure of documents in two ways:
An XML Schema is a set of rules to which a document must conform. It has hardcoded mechanisms for datatypes and the attributes and direct content of elements. Constraints outside these cannot be expressed in XML Schema. A common need is the conditional dependence (coupling) of one part of the document on another part: "if part A has this structure and/or values, then part B must have that structure and/or values. A CML example is: "if a molecule has less than four atoms, it cannot have any torsion elements". This requires a knowledge of the document context which XML Schema cannot provide.
XSLT (World wide Web Consortium, n.d.) was developed as a rule-based transformation language. It allows very powerful determination of context through XPath. The constraint above could be expressed as:
<xsl:template match="torsion">
<xsl:if test="count(../atomArray/atom)>3">
<xsl:message>TORSION REQUIRES FOUR ATOMS</xsl:message>
</xsl:if>
</xsl:template>
In principle, therefore, XML validation could take place through XSLT and not through Schemas. The Schematron approach (Schematron, n.d.) is essentially a mechanism for using such stylesheets to validate XML documents in place of a Schema. In practice we believe that XMLSchema is the cleanest approach for those things it does well (particularly datatypes), but that XSLT should be used for constraints that cannot be easily expressed with the current syntax. Fortunately it is easy to integrate the two approaches as XML Schema has an appinfo element for adding machine-processable documentation to an element or attribute. Certain tools can scan the appinfo and apply XSLT-based rules for additional validation.
There is a strong requirement for structural constraints in STM data. They often take forms like:
"If the boiling point is reported, the pressure must also be given".
"If the data are two dimensional then the matrix is of order 3, otherwise of order 4".
"If x has this value then y must be present".
In some cases this can be represented in XMLSchemas or DTDs. For example, one of us (Murray-Rust, 2001) has converted the SELF format (Kehiaian, 2001) for physicochemical data into XML. SELF consists of many different measurement types (e.g. critical point, vapour pressure by temperature) with a variety of numbers of independent and dependent variables. Each data structure (one per measurement type) can be represented by a DTD. Effectively the DTD fragment is stored with the dictionary entry for the measurement type and can be used to XML-validate the data instance. We can foresee this being a useful future development for STMML.
XML Schemas are complex. The formal XML Schema recommendations run to over 300 pages and require a 60 page primer to get started (World Wide Web Consortium, n.d.). We therefore introduce Schemas with examples, and also append the STMML schema itself as Appendix 2 to this article.
Schemas are designed to be easily documented, and since they are in XML, they can be transformed into common formats such as XHTML and using XSL-FO, into Acrobat PDF (Gkoutos, Murray-Rust, Rzepa and Wright, 2001a). They can be searched and can be reorganised into different presentations. Documentation is available for the schema itself and for most components such as elements, attributes, attributeGroups, etc. This allows programs to extract documentation directly from the schema and associate with the component being used, perhaps on an online help system or for automatic archival. The top-level element for this is annotation which can contain documentation for human readers and appinfo for machine processing. The latter is a major advance in that it allows a wide variety of functionality to be added on a per-element or per-attribute basis.
STMML uses a subset of the XMLSchema vocabulary:
"Top-level" elements
Content-related. These elements constrain the content of elements:
Occurrence counts for elements and the above constructs now have explicit attributes (minOccurs, maxOccurs which allow for greater power in representing cardinality.
This extract from STMML Schema shows many of the constructs that we use. It epitomises the re-use of STMML components to build a specialist element and relies on previous definition of some simpleTypes and attributeGroups. Comments are shown in italics.
This specifies the structure and vocabulary of the "crystal" element
<xsd:element name="crystal" id="el.crystal">
documentation...
<xsd:annotation>
<xsd:documentation>
<div class="summary">A container for crystallographic
cell parameters and spacegroup</div>
<div class="description">
<p>Required if
fractional coordinates are provided for a molecule.</p>
<p>There are precisely SIX child <tt>scalar</tt>s
to represent the cell lengths
and angles in that order. There are no default values; </p>
</div>
<div class="example"><pre>
example...
<molecule id="m1">
<crystal spacegroup="Fm3m" z="4">
<stm:scalar title="a" errorValue="0.001" units="angstrom">5.628</stm:scalar>
<stm:scalar title="b" errorValue="0.001" units="angstrom">5.628</stm:scalar>
<stm:scalar title="c" errorValue="0.001" units="angstrom">5.628</stm:scalar>
<stm:scalar title="alpha" errorValue="0">90</stm:scalar>
<stm:scalar title="beta" errorValue="0">90</stm:scalar>
<stm:scalar title="gamma" errorValue="0">90</stm:scalar>
</crystal>
<atomArray>
<atom id="a1" elementType="Na" formalCharge="1" xyzFract="0.0 0.0 0.0" xy2="+23.2 -21.0"/>
<atom id="a2" elementType="Cl" formalCharge="-1" xyzFract="0.5 0.0 0.0"/>
</atomArray>
</molecule>
</pre></div>
</xsd:documentation>
</xsd:annotation>
"complexType" can have both element children and attributes...
<xsd:complexType>
precisely 6 children allowed (the cell parameters).
<xsd:sequence>
<xsd:element ref="stm:scalar" minOccurs="6" maxOccurs="6"/>
</xsd:sequence>
an attribute describing the spacegroup...
<xsd:attribute name="spacegroup" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The spacegroup as a symbol</div>
<div class="description">There is no controlled vocabulary or
pattern at present. Hermann-Mauguin or Hall
symbols are recommended
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
another attribute (describing the number of molecules/cell).
This is restricted to be a non-negative integer...
<xsd:attribute name="z" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
<p>The number of molecules per cell. Molecules
are defined as the <tt>molecule</tt> which directly contains
the <tt>crystal</tt> element.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
more attributes (bundled in a group for ease of maintenance)...
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
</xsd:complexType>
</xsd:element>
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The main components are elements and attributes (Table 2). Elements are always declared as such, while attributes may be contained in elements, defined as simpleTypes, or bundled in groups of attributes (attributeGroups). This table gives a brief phrase describing each component, and some are described in more detail in the next section. Parts of the schema are primarily for ease of maintenance (simpleTypes rather than element-bound attributes, and attributeGroups) and are not elaborated here.
The whole schema (Appendix 2) is part of this "datument" publication and can be inspected or processed with specialist XMLSchema-aware tools such as Xerces (Xerces, n.d.). For example the STMML Schema itself has been transformed and styled using XSLT, and the examples included in the appinfo element have all themselves been validated with the STMML XMLSchema. Many technical authors will realise the benefit of a single self-consistent source of content; XSLT/XMLSchema allows it to be reworked without the likelihood of corruption through editing such as cut-and-paste or transformation in conventional document-processing tools.
We have shown how STMML as an XML-based markup language can cover many generic aspects of scientific information and how it has been developed as a re-usable core for more specific markup languages. The specification is through an XML Schema which can be used to validate STMML documents or fragments, and the schema itself (the "datument) has been used to validate and present through appropriate transformations all the examples included here.
The full Schema is part of this datument as Appendix 2 and via http://www.xml-cml.org/schema/stmml/ but because of its comprehensive nature we have added this synopsis for initial readers. Many details are omitted, but most of the significant examples are retained. All elements and the main generic attributes are described but individual attributes are usually omitted.
The synopsis is organised by the concepts:
<array size="5" title="value" dataType="xsd:decimal"> 1.23 2.34 3.45 4.56 5.67</array>
the size attribute is not mandatory but provides a useful validity check):
<array size="5" title="initials" dataType="xsd:string" delimiter="/">/A B//C/D-E/F/</array>
Note that the second array-element is the empty string ''.
<array title="mass" size="4" units="unit:g" errorBasis="observedStandardDeviation" minValues="10 11 10 9" maxValues="12 14 12 11" errorValues="1 2 1 1" dataType="xsd:float">11 12.5 10.9 10.2 </array>
<scalar
dataType="xsd:decimal"
errorValue="1.0"
errorBasis="observedStandardDeviation"
title="body weight"
dictRef="zoo:bodywt"
units="units:g">34.3</scalar>
<matrix id="m1" title="mattrix-1" dictRef="foo:bar" rows="3" columns="3" dataType="xsd:decimal" delimiter="|" matrixType="squareSymmetric" units="unit:m" >|1.1|1.2|1.3|1.2|2.2|2.3|1.3|2.3|3.3!</matrix>
<table rows="3" columns="2" title="people"> <array title="age" dataType="xsd:integer">3 5 7</array> <array title="name" dataType="xsd:string">Sue Fred Sandy</array> </table>
<list> <array title="animals">frog bear toad</array> <scalar title="weight" dataType="xsd:float">3.456</scalar> </list>
<list>
<array
>1.2,3.4 3.2,4.5 6.7,23.1 </array>
<array delimiter="/"
>/1.2 3.4/3.2 4.5/6.7 23.1/</array>
</list>
<list>
<array>1.2,3.4,1.2
3.2,4.5,7.3 6.7,23.1,5.6 </array>
<array delimiter="/"
>/1.2 3.4 3.3/3.2 4.5 4.5/6.7 23.1 5.6/</array>
</list>
an enumerated type for all builtin allowed dataTypes in STM
<list xmlns="http://www.xml-cml.org/schema/cml2/core"> <scalar dataType="xsd:boolean" title="she loves me">true</scalar> <scalar dataType="xsd:float" title="x">23.2</scalar> <scalar dataType="xsd:duration" title="egg timer">PM4</scalar> <scalar dataType="xsd:dateTime" title="current data and time">2001-02-01:00:30</scalar> <scalar dataType="xsd:time" title="wake up">06:00</scalar> <scalar dataType="xsd:date" title="where is it">1752-09-10</scalar> <scalar dataType="xsd:anyURI" title="CML site">http://www.xml-cml.org/</scalar> <scalar dataType="xsd:QName" title="CML atom">cml:atom</scalar> <scalar dataType="xsd:normalizedString" title="song">the mouse ran up the clock</scalar> <scalar dataType="xsd:language" title="UK English">en-GB</scalar> <scalar dataType="xsd:Name" title="atom">atom</scalar> <scalar dataType="xsd:ID" title="XML ID">_123</scalar> <scalar dataType="xsd:integer" title="the answer">42</scalar> <scalar dataType="xsd:nonPositiveInteger" title="zero">0</scalar> </list>
<array size="4" delimiter="|">|A|B12||D and E|</array>
The values in the array are
"A", "B12", "" (empty string) and "D and E"
note the spaces
<atomArray xmlns="http://www.xml-cml.org/schema/cml2/core" x2="1.2 2.3 3.4 5.6"/>
<matrix id="m1" title="mattrix-1" dictRef="foo:bar" rows="3" columns="3" dataType="xsd:decimal" delimiter="|" matrixType="squareSymmetric" units="unit:m" >|1.1|1.2|1.3|1.2|2.2|2.3|1.3|2.3|3.3!</matrix>
A count multiplier for certain elements
<list> <object title="frog" count="10"/> <action title="step3" count="3"> <p>Add 10 ml reagent</p> </action> </list>
<alternative type="userType" userType="biological name">SusScrofa</alternative>
| id | idType |
| title | xsd:string |
| convention | namespaceRefType | [default=CML] |
<bond convention="fooChem" order="-5" xmlns:fooChem="http://www.fooChem/conventions"/>
<scalar
dataType="xsd:decimal"
errorValue="1.0"
errorBasis="observedStandardDeviation"
title="body weight"
dictRef="zoo:bodywt"
units="units:g">34.3</scalar>
<scalar dataType="xsd:float" maxValue="20" minValue="12">15</scalar>
<scalar dataType="xsd:float" maxValue="20" minValue="12">15</scalar>
<list> <!-- dictRef is of namespaceRefType --> <scalar dictRef="chem:mpt">123</scalar> <!-- error --> <scalar dictRef="mpt23">123</scalar> </list>
<actionList title="boiling two eggs for breakfast"> <!-- start cooking at 9am --> <action title="turn on heat" start="T09:00:00" convention="xsd"/> <!-- human readable description of time to start action --> <action title="put egg into pan" startCondition="water is boiling" count="2"/> <!-- the duration is expressed in ISO8601 format --> <action title="boil eggs for 4 minutes" duration="4" units="units:min"/> <!-- action immediately follows last action --> <action title="remove egg from pan" count="1"/> <action title="boil second egg for a bit longer" duration="about half a minute"/> <!-- action immediately follows last action --> <action title="remove egg from pan" count="1"/> </actionList>
<actionList title="preparation of silanols">
<p>This is a conversion of a chemical synthesis to STMML. We
have deliberately not marked up the chemistry in this example!</p>
<action title="step2">
<p>Take 1 mmol of the diol and dissolve in dioxan in
<object title="flask">
<scalar title="volume" units="units:ml">25</scalar>
</object>
</p>
</action>
<action title="step2">
<p>Place flask in water bath with magnetic stirrer</p>
</action>
<!-- wait until certain condition -->
<actionList endCondition="bath temperature stabilised"/>
<action title="step3">
<p>Add 0.5 ml 1 M H2SO4</p>
</action>
<!-- carry out reaction -->
<actionList endCondition="reaction complete; no diol spot remains on TLC">
<actionList title="check tlc">
<!-- wait for half an hour -->
<action duration="half an hour"/>
<action title="tlc">
<p>extract solution and check diol spot on TLC</p>
</action>
</actionList>
</actionList>
<!-- work up reaction -->
<action title="step5">
<p>Add 10 ml water to flask</p>
</action>
<action title="step6">
<p>Neutralize acid with 10% NaHCO3</p>
</action>
<action title="step7" count="3">
<p>Extract with 10ml ether</p>
</action>
<action title="step8">
<p>Combine ether layers</p>
</action>
<action title="step9" count="2">
<p>Wash ether with 10 ml water</p>
</action>
<action title="step10">
<p>Wash ether with 10 ml saturated NaCl</p>
</action>
<action title="step11">
<p>Dry over anhydrous Na2SO4 and remove solvent on rotary evaporator</p>
</action>
</actionList>
<!-- demonstrating parallel and sequential actions -->
<actionList order="parallel" endCondition="all food cooked">
<!-- meat and potatoes are cooked in parallel -->
<actionList title="meat">
<action title="cook" endCondition="cooked">
<p>Roast meat</p>
</action>
<action><p>Keep warm in oven</p></action>
</actionList>
<actionList title="vegetables">
<actionList title="cookVeg" endCondition="cooked">
<action title="boil water" endCondition="water boiling">
<p>Heat water</p>
</action>
<action title="cook" endCondition="potatoes cooked">
<p>Cook potatoes</p>
</action>
</actionList>
<action><p>Keep warm in oven</p></action>
</actionList>
</actionList>
<object title="frog" type="amphibian" count="5"> <scalar dataType="xsd:float" title="length" units="unit:cm">5</scalar> </object>
<stm:dictionary xmlns:stm="http://www.xml-cml.org/schema/stmml">
<stm:entry id="a001" term="Amplitude for charge density mixing"
dataType="stm:decimal"
units="arbitrary">
<stm:annotation>
<stm:documentation>
<div class="summary">Amplitude for charge density mixing</div>
<div class="description">Not yet filled in...</div>
</stm:documentation>
</stm:annotation>
<stm:alternative type="abbreviation">CDMixAmp</stm:alternative>
</stm:entry>
</stm:dictionary>
dictionary can be used in an instance document to reference the dictionary used. Example:
<list>
<dictionary
dictRef="core" href="../dictionary/coreDict.xml"/>
<!-- ... -->
<scalar dictRef="core:frog" title="specimens">Frogs</scalar>
</list>
<s:entry id="a003" term="alpha" dataType="float" minInclusive="0.0" maxInclusive="180.0" recommendedUnits="degrees" xmlns:s="http://www.xml-cml.org/schema/stmml"> <s:definition>The alpha cell angle</s:definition> </s:entry>
<entry id="a003" term="matrix1" dataType="float" rows="3" columns="4" unitType="unit:length" minInclusive="0.0" maxInclusive="100.0" recommendedUnits="unit:m" totalDigits="8" fractionDigits="3"> <definition>A matrix of lengths</definition> <description>A data instance will have a matrix which points to this entry (e.g. dictRef="foo:matrix1"). The matrix must be 3*4, composed of floats in 8.3 format, of type length, values between 0 and 100 and with recommended units metres. </description> </entry>
The definition for a dictionary entry, scientific units, etc.
<entry id="a7" term="Allosteric enzyme">
<definition>An <a href="#e3">enzyme</a>
that contains a region to which small, regulatory molecules
("effectors") may bind in addition to and separate from the
substrate binding site and thereby affect the catalytic
activity.
</definition>
<description>On binding the effector, the catalytic activity of the
<strong>enzyme</strong> towards the substrate may be enhanced, in
which case the effector is an activator, or reduced, in which case
it is a de-activator or inhibitor.
</description>
</entry>
<entry id="a7" term="Allosteric enzyme">
<definition>An <a href="#e3">enzyme</a>
that contains a region to which small, regulatory molecules
("effectors") may bind in addition to and separate from the
substrate binding site and thereby affect the catalytic
activity.
</definition>
<description>On binding the effector, the catalytic activity of the
<strong>enzyme</strong> towards the substrate may be enhanced, in
which case the effector is an activator, or reduced, in which case
it is a de-activator or inhibitor.
</description>
</entry>
<entry term="crystal system" id="cryst1" dataType="string">
<definition>A crystal system</definition>
<enumeration value="triclinic">
<annotation>
<documentation>
<div class="summary">No constraints on lengths and angles</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="monoclinic">
<annotation>
<documentation>
<div class="summary">Two cell angles are right angles; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="orthorhombic">
<annotation>
<documentation>
<div class="summary">All three angles are right angles; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="tetragonal">
<annotation>
<documentation>
<div class="summary">Fourfold axis of symmetry; All three angles are right angles; two equal cell lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="trigonal">
<annotation>
<documentation>
<div class="summary">Threefold axis of symmetry; Two angles are right angles; one is 120 degrees; two equal lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="hexagonal">
<annotation>
<documentation>
<div class="summary">Sixfold axis of symmetry; Two angles are right angles; one is 120 degrees; two equal lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="cubic">
<annotation>
<documentation>
<div class="summary">All three angles are right angles; all cell lengths are equal</div>
</documentation>
</annotation>
</enumeration>
</entry>
An alternative name for an entry
<entry term="ammonia" id="a1"> <alternative type="synonym">Spirits of hartshorn</alternative> </entry>
<stm:entry id="a14" term="Autoreceptor"
xmlns:stm="http://www.xml-cml.org/schema/cml2/core">
<stm:definition>An <strong>autoreceptor</strong>, present at a nerve ending, is
a <a href="#r1">receptor</a>
that regulates, via positive or negative feedback processes, the
synthesis and/or release of its own physiological ligand.
</stm:definition>
<stm:relatedEntry type="seeAlso" href="#h4">Heteroreceptor).</stm:relatedEntry>
</stm:entry>
A documentation container similar to annotation in XML Schema.
<entry term="matrix">
<annotation>
<documentation>This refers to mathematical matrices</documentation>
<appinfo>... some code to describe and support matrices ...</appinfo>
</annotation>
</entry>
<stm:documentation id="source" xmlns:stm="http://www.xml-cml.org/schema/stmml"> Transcribed from IUPAC website </stm:documentation>
A container similar to appinfo in XML Schema.
An example in XSLT where an element foo calls a bespoke template
.
<s:appinfo
xmlns:s="http://www.xml-cml.org/schema/cml2/core"
xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="foo">
<call-template name="processFoo"/>
</template>
</s:appinfo>
| dictRef | namespaceRefType |
A reference to a dictionary entry.
<scalar dataType="xsd:float" title="surfaceArea" dictRef="cmlPhys:surfArea" xmlns:cmlPhys="http://www.xml-cml.org/dict/physical" units="units:cm2">50</scalar>
<stm:list xmlns:stm="http://www.xml-cml.org/schema/stmml">
<stm:observation>
<p>We observed <object count="3" dictRef="#p1"/>
constructing dwellings of different material</p>
</stm:observation>
<stm:entry id="p1" term="pig">
<stm:definition>A domesticated animal.</stm:definition>
<stm:description>Predators include wolves</stm:description>
<stm:description class="scientificName">Sus scrofa</stm:description>
</stm:entry>
</stm:list>
<list>
<metadataList>
<metadata name="dc:coverage" content="Europe"/>
<metadata name="dc:description" content="Ornithological chemistry"/>
<metadata name="dc:identifier" content="ISBN:1234-5678"/>
<metadata name="dc:format" content="printed"/>
<metadata name="dc:relation" content="abc:def123"/>
<metadata name="dc:rights" content="licence:GPL"/>
<metadata name="dc:subject" content="Informatics"/>
<metadata name="dc:title" content="birds"/>
<metadata name="dc:type" content="bird books on chemistry"/>
<metadata name="dc:contributor" content="Tux Penguin"/>
<metadata name="dc:creator" content="author"/>
<metadata name="dc:publisher" content="Penguinone publishing"/>
<metadata name="dc:source" content="penguinPub"/>
<metadata name="dc:language" content="en-GB"/>
<metadata name="dc:date" content="1752-09-10"/>
</metadataList>
<metadataList>
<metadata name="cmlm:safety" content="mostly harmless"/>
<metadata name="cmlm:insilico" content="electronically produced"/>
<metadata name="cmlm:structure" content="penguinone"/>
<metadata name="cmlm:reaction" content="synthesis of penguinone"/>
<metadata name="cmlm:identifier" content="smiles:O=C1C=C(C)C(C)(C)C(C)=C1"/>
</metadataList>
</list>
<list>
<metadataList>
<metadata name="dc:coverage" content="Europe"/>
<metadata name="dc:description" content="Ornithological chemistry"/>
<metadata name="dc:identifier" content="ISBN:1234-5678"/>
<metadata name="dc:format" content="printed"/>
<metadata name="dc:relation" content="abc:def123"/>
<metadata name="dc:rights" content="licence:GPL"/>
<metadata name="dc:subject" content="Informatics"/>
<metadata name="dc:title" content="birds"/>
<metadata name="dc:type" content="bird books on chemistry"/>
<metadata name="dc:contributor" content="Tux Penguin"/>
<metadata name="dc:creator" content="author"/>
<metadata name="dc:publisher" content="Penguinone publishing"/>
<metadata name="dc:source" content="penguinPub"/>
<metadata name="dc:language" content="en-GB"/>
<metadata name="dc:date" content="1752-09-10"/>
</metadataList>
<metadataList>
<metadata name="cmlm:safety" content="mostly harmless"/>
<metadata name="cmlm:insilico" content="electronically produced"/>
<metadata name="cmlm:structure" content="penguinone"/>
<metadata name="cmlm:reaction" content="synthesis of penguinone"/>
<metadata name="cmlm:identifier" content="smiles:O=C1C=C(C)C(C)(C)C(C)=C1"/>
</metadataList>
</list>
<unitType id="energy" name="energy"> <dimension name="length"/> <dimension name="mass"/> <dimension name="time" power="-1"/> </unitType>
<unitType id="energy" name="energy"> <dimension name="length"/> <dimension name="mass"/> <dimension name="time" power="-1"/> </unitType>
<stm:unitList xmlns:stm="http://www.xml-cml.org/schema/stmml"> <!-- ======================================================================= --> <!-- ========================= fundamental types =========================== --> <!-- ======================================================================= --> <stm:unitType id="length" name="length"> <stm:dimension name="length"/> </stm:unitType> <stm:unitType id="time" name="time"> <stm:dimension name="time"/> </stm:unitType> <!-- ... --> <stm:unitType id="dimensionless" name="dimensionless"> <stm:dimension name="dimensionless"/> </stm:unitType> <!-- ======================================================================= --> <!-- ========================== derived types ============================== --> <!-- ======================================================================= --> <stm:unitType id="acceleration" name="acceleration"> <stm:dimension name="length"/> <stm:dimension name="time" power="-2"/> </stm:unitType> <!-- ... --> <!-- ======================================================================= --> <!-- ====================== fundamental SI units =========================== --> <!-- ======================================================================= --> <stm:unit id="second" name="second" unitType="time"> <stm:description>The SI unit of time</stm:description> </stm:unit> <stm:unit id="meter" name="meter" unitType="length" abbreviation="m"> <stm:description>The SI unit of length</stm:description> </stm:unit> <!-- ... --> <stm:unit id="kg" name="nameless" unitType="dimensionless" abbreviation="nodim"> <stm:description>A fictitious parent for dimensionless units</stm:description> </stm:unit> <!-- ======================================================================= --> <!-- ===================== derived SI units ================================ --> <!-- ======================================================================= --> <stm:unit id="newton" name="newton" unitType="force"> <stm:description>The SI unit of force</stm:description> </stm:unit> <!-- ... --> <!-- multiples of fundamental SI units --> <stm:unit id="g" name="gram" unitType="mass" parentSI="kg" multiplierToSI="0.001" abbreviation="g"> <stm:description>0.001 kg. </stm:description> </stm:unit> <stm:unit id="celsius" name="Celsius" parentSI="k" multiplierToSI="1" constantToSI="273.18"> <stm:description><p>A common unit of temperature</p></stm:description> </stm:unit> <!-- fundamental non-SI units --> <stm:unit id="inch" name="inch" parentSI="meter" abbreviation="in" multiplierToSI="0.0254" > <stm:description>An imperial measure of length</stm:description> </stm:unit> <!-- derived non-SI units --> <stm:unit id="l" name="litre" unitType="volume" parentSI="meterCubed" abbreviation="l" multiplierToSI="0.001"> <stm:description>Nearly 1 dm**3 This is not quite exact</stm:description> </stm:unit> <!-- ... --> <stm:unit id="fahr" name="fahrenheit" parentSI="k" abbreviation="F" multiplierToSI="0.55555555555555555" constantToSI="-17.777777777777777777"> <stm:description>An obsolescent unit of temperature still used in popular meteorology</stm:description> </stm:unit> </stm:unitList>
<?xml version="1.0" encoding="utf-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.xml-cml.org/schema/stmml" xmlns:sch="http://www.ascc.net/xml/schematron"
targetNamespace="http://www.xml-cml.org/schema/stmml" elementFormDefault="qualified">
<xsd:annotation>
<xsd:documentation xml:lang="en">
<div class="curation">
<ul>
<li>created by hand
2001-11-20</li>
<li>First draft 2001-11-20</li>
</ul>
<p>STMML supports domain-independent STM information components</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:appinfo>
<sch:title>Schematron validation</sch:title>
<sch:ns uri="http://www.xml-cml.org/schema/stmml"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
<div class="heading">Data Types and Data Structure</div>
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Overview</div>
<div class="description">
<p>STMML defines a number of data types suited to STM. It also defines
a number of complex data strucures such as arrays, matrices and tables.
the constraints are sometimes created through elements and sometimes
through attributes. We classify the general components as follows:</p>
<p><b>Abstract Data Structures</b></p>
<ul>
<li><a href="el.scalar">scalar</a>. A scalar quantity, expressible as a string, but
with many optional facets such as errors, units, ranges, etc. Most elements
may have <a href="st.countType">countType</a> attribute to indicate more than
one instance.</li>
<li><a href="el.array">array</a>. An array of homogeneous <tt>scalar</tt>s
whose size is described by <a href="st.sizeType">sizeType</a>. <a href="st.delimiterType">
Delimiter</a>s in string representations can ve varied.</li>
<li><a href="el.matrix">matrix</a>. A rectangular (often square) matrix of
homogeneous <tt>scalar</tt>s. Many matrices have special functions
(see <a href="el.matrixType">matrixType</a>) such as geometric
transformations</li>
<li><a href="el.table">table</a>. An table where the columns are homogeneous
<tt>array</tt>s. </li>
<li><a href="el.list">list</a>. A list of heterogeneous components from any
namespace.</li>
<li><a href="st.sizeType">sizeType</a>. Size of arrays</li>
<li><a href="st.delimiterType">delimiterType</a>. A lexical delimiter</li>
</ul>
<p><b>Links and References</b></p>
<ul>
<li><a href="el.link">link</a>. Support for simple hyperlinks and link structures</li>
<li><a href="st.refType">refType</a>. A reference to an element</li>
<li><a href="st.namespaceRefType">namespaceRefType</a>. A reference to an element, including
namespace-like prefixes</li>
</ul>
<p><b>Data-based simpleTypes</b></p>
<ul>
<li><a href="st.coordinate2Type">coordinate2Type</a>. A 2-D coordinate</li>
<li><a href="st.coordinate3Type">coordinate3Type</a>. A 3-D coordinate</li>
<li><a href="st.dataTypeType">dataTypeType</a>. An enumeration of
data types (similar to those in XML Schema).</li>
<li><a href="st.errorBasisType">errorBasisType</a>. Basis of numeric error estimates</li>
<li><a href="st.minType">minType</a>. Minimum value</li>
<li><a href="st.maxType">maxType</a>. Maximum value</li>
</ul>
<p><b>Common attribute types</b></p>
<ul>
<li><a href="st.idType">idType</a>. Specifies lexical patterns for IDs</li>
<li><a href="attGp.idGroup">idGroup</a>. ID attribute (highly encouraged)</li>
<li><a href="attGp.titleGroup">titleGroup</a>. Title attribute (highly encouraged)</li>
<li><a href="attGp.convGroup">convGroup</a>. Convention attribute</li>
<li><a href="st.userTypeType">userTypeType</a>. Allows use to specify their own
attributes</li>
</ul>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Data structure</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="array" id="el.array">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
A homogenous 1-dimensional array of similar objects.</div>
<div class="description">
<p>
<tt>array</tt> manages a homogenous 1-dimensional array of similar objects. These
can be encoded as strings (i.e. XSD-like datatypes) and are concatenated as
string content. The size of the array should always be >= 1.
</p>
<p>The default delimiter is whitespace. The <tt>normalize-space()</tt> function of
XSLT could be used to normalize all whitespace to single spaces and this would not affect
the value of the array elements. To extract the elements <tt>java.lang.StringTokenizer</tt>
could be used. If the elements themselves contain whitespace then a different delimiter
must be used and is identified through the <tt>delimiter</tt> attribute. This method is
mandatory if it is required to represent empty strings. If a delimiter is used it MUST
start and end the array - leading and trailing whitespace is ignored. Thus <tt>size+1</tt>
occurrences of the delimiter character are required. If non-normalized whitespace is to be
encoded (e.g. newlines, tabs, etc) you are recommended to translate it character-wise
to XML character entities.
</p>
<p>Note that normal Schema validation tools cannot validate the elements
of <b>array</b> (they are defined as <tt>string</tt>) However if the string is
split, a temporary schema
can be constructed from the type and used for validation. Also the type
can be contained in a dictionary and software could decide to retrieve this
and use it for validation.</p>
<p>When the elements of the <tt>array</tt> are not simple scalars
(e.g. <a href="el.scalar">scalar</a>s with a value and an error, the
<tt>scalar</tt>s should be used as the elements. Although this is
verbose, it is simple to understand. If there is a demand for
more compact representations, it will be possible to define the
syntax in a later version.</p>
</div>
<div class="example">
<pre>
<array size="5" title="value"
dataType="xsd:decimal"> 1.23 2.34 3.45 4.56 5.67</array>
</pre>
<p>the <tt>size</tt> attribute is not mandatory but provides a useful validity
check): </p>
</div>
<div class="example">
<pre>
<array size="5" title="initials" dataType="xsd:string"
delimiter="/">/A B//C/D-E/F/</array>
</pre>
<p>Note that the second array-element is the empty string ''.</p>
</div>
<div class="example">
<pre>
<array title="mass" size="4"
units="unit:g"
errorBasis="observedStandardDeviation"
minValues="10 11 10 9"
maxValues="12 14 12 11"
errorValues="1 2 1 1"
dataType="xsd:float">11 12.5 10.9 10.2
</array>
</pre>
</div>
</xsd:documentation>
<xsd:appinfo>
<sch:pattern xmlns="http://www.ascc.net/xml/schematron" name="array">
</sch:pattern>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="dataType" type="dataTypeType" default="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">all elements of the array must have the same dataType</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="errorValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of error values for numeric arrays</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="errorBasis" type="errorBasisType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A string describing the basis of the errors</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="minValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of minimum values for numeric arrays</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="maxValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of maximum values for numeric arrays</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="units" type="unitsType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">a string denoting the units (recommended for numeric quantities!!).
All elements must have the same units</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="delimiter" type="delimiterType"/>
<xsd:attribute name="size" type="xsd:positiveInteger"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="scalar" id="el.scalar">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An element to hold scalar data.</div>
<div class="description">
<p><tt>scalar</tt> holds scalar data under a single
generic container. The semantics are usually resolved by
linking to a dictionary.
<b>scalar</b> defaults to a scalar string but
has attributes which affect the type.
</p>
<p><tt>scalar</tt> does not necessarily reflect a physical object (for which
<a href="el.object">object</a> should be used). It may reflect a property of an object
such as temperature, size, etc. </p>
<p>Note that normal Schema validation tools cannot validate the data type
of <b>scalar</b> (it is defined as <tt>string</tt>), but that a temporary schema
can be constructed from the type and used for validation. Also the type
can be contained in a dictionary and software could decide to retrieve this
and use it for validation.</p>
</div>
<div class="example">
<pre>
<scalar
dataType="xsd:decimal"
errorValue="1.0"
errorBasis="observedStandardDeviation"
title="body weight"
dictRef="zoo:bodywt"
units="units:g">34.3</scalar>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="dataType" type="dataTypeType" default="xsd:string"/>
<xsd:attribute name="errorValue" type="xsd:decimal"/>
<xsd:attribute name="errorBasis" type="errorBasisType"/>
<xsd:attribute name="minValue" type="minType"/>
<xsd:attribute name="maxValue" type="maxType"/>
<xsd:attribute name="units" type="unitsType"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="matrix" id="el.matrix">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A rectangular matrix of any quantities</div>
<div class="description"><p>By default <tt>matrix</tt> represents
a rectangular matrix of any quantities
representable as XSD or STMML dataTypes. It consists of
<tt>rows*columns</tt> elements, where <tt>columns</tt> is the
fasting moving index. Assuming the elements are counted from 1 they are
ordered <tt>V[1,1],V[1,2],...V[1,columns],V[2,1],V[2,2],...V[2,columns],
...V[rows,1],V[rows,2],...V[rows,columns]</tt></p>
<p>By default whitespace is used to separate matrix elements; see
<a href="el.array">array</a> for details. There are NO characters or markup
delimiting the end of rows; authors must be careful!. The <tt>columns</tt>
and <tt>rows</tt> attributes have no default values; a row vector requires
a <tt>rows</tt> attribute of 1.</p>
<p><tt>matrix</tt> also supports many types of square matrix, but at present we
require all elements to be given, even if the matrix is symmetric, antisymmetric
or banded diagonal. The <tt>matrixType</tt> attribute allows software to
validate and process the type of matrix.</p>
</div>
<div class="example">
<pre>
<matrix id="m1" title="mattrix-1" dictRef="foo:bar"
rows="3" columns="3" dataType="xsd:decimal"
delimiter="|" matrixType="squareSymmetric" units="unit:m"
>|1.1|1.2|1.3|1.2|2.2|2.3|1.3|2.3|3.3!</matrix>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="dataType" type="dataTypeType" default="xsd:float"/>
<xsd:attribute name="delimiter" type="delimiterType"/>
<xsd:attribute name="rows" type="sizeType" use="required">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>Number of rows</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="columns" type="sizeType" use="required">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>Number of columns</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="units" type="unitsType">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>units (recommended for numeric quantities!!)</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="matrixType" type="matrixType">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>Type of matrix (mainly square ones)</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="errorValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of error values for numeric matrices</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="errorBasis" type="errorBasisType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A string describing the basis of the errors</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="minValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of minimum values for numeric matrices</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="maxValues" type="floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">an optional array of maximum values for numeric matrices</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="table" id="el.table">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A rectangular table of any quantities</div>
<div class="description"><p>By default <tt>table</tt>
represents a rectangular table of any quantities
representable as XSD or STMML dataTypes. The default layout is columnwise,
with <tt>columns</tt> columns,
where each column is a (homogeneous) <a href="el.array">array</a> of
size <tt>rows</tt> data. This is the "normal" orientation of data tables
but the table display could be transposed by XSLT transformation if required.
Access is to columns, and thence to the data within them. DataTyping, delimiters,
etc are delegated to the arrays, which must all be of the same size. For
verification it is recommended that every array carries a <tt>size</tt>
attribute.
</p>
</div>
<div class="example"><pre><table rows="3" columns="2" title="people">
<array title="age" dataType="xsd:integer">3 5 7</array>
<array title="name" dataType="xsd:string">Sue Fred Sandy</array>
</table>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="array" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="rows" type="sizeType" use="required">
<xsd:annotation>
<xsd:documentation>
<div class="description"><p>Number of rows</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="columns" type="sizeType" use="required">
<xsd:annotation>
<xsd:documentation>
<div class="description"><p>Number of columns</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="list" id="el.list">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A generic container with no implied semantics</div>
<div class="description"><p>
A generic container with no implied semantics. It just contains
things and can have attributes which bind conventions to it. It could often
act as the root element in an STM document.</p>
</div>
<div class="example">
<pre>
<list>
<array title="animals">frog bear toad</array>
<scalar title="weight" dataType="xsd:float">3.456</scalar>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="type" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Data-based simpleTypes</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType name="coordinate2Type" id="st.coordinate2Type">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An x/y coordinate pair</div>
<div class="description">
<p>An x/y coordinate pair consisting of
two real numbers, separated by whitespace or a comma.
In arrays and matrices, it may be useful to set a separate delimiter</p>
</div>
<div class="example">
<pre>
<list>
<array
>1.2,3.4 3.2,4.5 6.7,23.1 </array>
<array delimiter="/"
>/1.2 3.4/3.2 4.5/6.7 23.1/</array>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="\s*([-]|[+])?\d*\.?\d*(\s+|[,])([-]|[+])?\d*\.?\d*\s*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="coordinate3Type" id="st.coordinate3Type">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An x/y/z coordinate triple</div>
<div class="description">
<p>An x/y/z coordinate triple consisting of
three real numbers, separated by whitespace or commas.
In arrays and matrices, it may be useful to set a separate delimiter</p>
</div>
<div class="example">
<pre>
<list>
<array>1.2,3.4,1.2
3.2,4.5,7.3 6.7,23.1,5.6 </array>
<array delimiter="/"
>/1.2 3.4 3.3/3.2 4.5 4.5/6.7 23.1 5.6/</array>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="\s*([-]|[+])?\d*\.?\d*(\s+|[,])([-]|[+])?\d*\.?\d*(\s+|[,])([-]|[+])?\d*\.?\d*\s*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="dataTypeType" id="st.dataTypeType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>an enumerated type for all builtin allowed dataTypes in STM</p>
</div>
<div class="description">
<p>
<tt>dataTypeType</tt> represents an enumeration of allowed dataTypes
(at present identical with those in XML-Schemas (Part2- datatypes).
This means that implementers should be able to use standard XMLSchema-based
tools for validation without major implementation problems.
</p>
<p>It will often be used an an attribute on
<a href="el.scalar">scalar</a>,
<a href="el.array">array</a> or
<a href="el.matrix">matrix</a>
elements.</p>
</div>
<div class="example">
<pre>
<list xmlns="http://www.xml-cml.org/schema/core">
<scalar dataType="xsd:boolean" title="she loves me">true</scalar>
<scalar dataType="xsd:float" title="x">23.2</scalar>
<scalar dataType="xsd:duration" title="egg timer">PM4</scalar>
<scalar dataType="xsd:dateTime" title="current data and time">2001-02-01:00:30</scalar>
<scalar dataType="xsd:time" title="wake up">06:00</scalar>
<scalar dataType="xsd:date" title="where is it">1752-09-10</scalar>
<scalar dataType="xsd:anyURI" title="CML site">http://www.xml-cml.org/</scalar>
<scalar dataType="xsd:QName" title="CML atom">cml:atom</scalar>
<scalar dataType="xsd:normalizedString" title="song">the mouse ran up the clock</scalar>
<scalar dataType="xsd:language" title="UK English">en-GB</scalar>
<scalar dataType="xsd:Name" title="atom">atom</scalar>
<scalar dataType="xsd:ID" title="XML ID">_123</scalar>
<scalar dataType="xsd:integer" title="the answer">42</scalar>
<scalar dataType="xsd:nonPositiveInteger" title="zero">0</scalar>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="xsd:string"/>
<xsd:enumeration value="xsd:boolean"/>
<xsd:enumeration value="xsd:float"/>
<xsd:enumeration value="xsd:double"/>
<xsd:enumeration value="xsd:decimal"/>
<xsd:enumeration value="xsd:duration"/>
<xsd:enumeration value="xsd:dateTime"/>
<xsd:enumeration value="xsd:time"/>
<xsd:enumeration value="xsd:date"/>
<xsd:enumeration value="xsd:gYearMonth"/>
<xsd:enumeration value="xsd:gYear"/>
<xsd:enumeration value="xsd:gMonthDay"/>
<xsd:enumeration value="xsd:gDay"/>
<xsd:enumeration value="xsd:gMonth"/>
<xsd:enumeration value="xsd:hexBinary"/>
<xsd:enumeration value="xsd:base64Binary"/>
<xsd:enumeration value="xsd:anyURI"/>
<xsd:enumeration value="xsd:QName"/>
<xsd:enumeration value="xsd:NOTATION"/>
<xsd:enumeration value="xsd:normalizedString"/>
<xsd:enumeration value="xsd:token"/>
<xsd:enumeration value="xsd:language"/>
<xsd:enumeration value="xsd:IDREFS"/>
<xsd:enumeration value="xsd:ENTITIES"/>
<xsd:enumeration value="xsd:NMTOKEN"/>
<xsd:enumeration value="xsd:NMTOKENS"/>
<xsd:enumeration value="xsd:Name"/>
<xsd:enumeration value="xsd:NCName"/>
<xsd:enumeration value="xsd:ID"/>
<xsd:enumeration value="xsd:IDREF"/>
<xsd:enumeration value="xsd:ENTITY"/>
<xsd:enumeration value="xsd:integer"/>
<xsd:enumeration value="xsd:nonPositiveInteger"/>
<xsd:enumeration value="xsd:negativeInteger"/>
<xsd:enumeration value="xsd:long"/>
<xsd:enumeration value="xsd:int"/>
<xsd:enumeration value="xsd:short"/>
<xsd:enumeration value="xsd:byte"/>
<xsd:enumeration value="xsd:nonNegativeInteger"/>
<xsd:enumeration value="xsd:unsignedLong"/>
<xsd:enumeration value="xsd:unsignedInt"/>
<xsd:enumeration value="xsd:unsignedShort"/>
<xsd:enumeration value="xsd:unsignedByte"/>
<xsd:enumeration value="xsd:positiveInteger"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="summary">Array-based simpleTypes</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType name="sizeType" id="st.sizeType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The size of an array</div>
<div class="description">
<p>The size of an array. Redundant, but serves as a check
for processing software (useful if delimiters are used)</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:positiveInteger"/>
</xsd:simpleType>
<xsd:simpleType name="delimiterType" id="st.delimiterType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A non-whitespace character used in arrays to separate components</div>
<div class="description">
<p>Some STMML elements (such as <a href="el.array">array</a>) have
content representing concatenated values. The default separator is
whitespace (which can be normalised) and this should be used whenever
possible. However in some cases the values are empty, or contain whitespace or other
problematic punctuation, and a delimiter is required.</p>
<p>Note that the content string MUST start and end with the delimiter so
there is no ambiguity as to what the components are. Only printable
characters from the ASCII character set should be used, and character
entities should be avoided.</p>
<p>When delimiters are used to separate precise whitespace this should always
consist of spaces and not the other allowed whitespace characters
(newline, tabs, etc.). If the latter are important it is probably best to redesign
the application.</p>
</div>
<div class="example">
<pre>
<array size="4" delimiter="|">|A|B12||D and E|</array>
<em>The values in the array are</em>
"A", "B12", "" (empty string) and "D and E"
<em>note the spaces</em>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="floatArrayType" id="st.floatArrayType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An array of floats</div>
<div class="description">
<p>An array of floats or other real numbers.
Not used in STM Schema, but re-used by CML.
There is no schema-checking of values, unfortunately.</p>
</div>
<div class="example">
<pre>
<atomArray xmlns="http://www.xml-cml.org/schema/core"
x2="1.2 2.3 3.4 5.6"/>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="matrixType" id="st.matrixType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Allowed <a href="el.matrix">matrix</a> types</div>
<div class="description"><p>Allowed <tt>matrix</tt> types.
These are mainly square matrices</p></div>
<div class="example">
<pre>
<matrix id="m1" title="mattrix-1" dictRef="foo:bar"
rows="3" columns="3" dataType="xsd:decimal"
delimiter="|" matrixType="squareSymmetric" units="unit:m"
>|1.1|1.2|1.3|1.2|2.2|2.3|1.3|2.3|3.3!</matrix>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="rectangular"/>
<xsd:enumeration value="square"/>
<xsd:enumeration value="squareSymmetric"/>
<xsd:enumeration value="squareAntisymmetric"/>
<xsd:enumeration value="diagonal">
<xsd:annotation>
<xsd:documentation>
<div class="description">Symmetric. Elements are zero except on the diagonal</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="upperTriangular">
<xsd:annotation>
<xsd:documentation>
<div class="description">Square. Elements are zero below the diagonal
<pre>
1 2 3 4
0 3 5 6
0 0 4 8
0 0 0 2
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="lowerTriangular">
<xsd:annotation>
<xsd:documentation>
<div class="description">Symmetric. Elements are zero except on the diagonal</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="unitary"/>
<xsd:enumeration value="rowEigenvectors"/>
<xsd:enumeration value="rotation22"/>
<xsd:enumeration value="rotationTranslation32"/>
<xsd:enumeration value="homogeneous33"/>
<xsd:enumeration value="rotation33"/>
<xsd:enumeration value="rotationTranslation43"/>
<xsd:enumeration value="homogeneous44"/>
<xsd:enumeration value="square"/>
<xsd:enumeration value="square"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="countType" id="st.countType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>A count multiplier for certain elements</p>
</div>
<div class="description">
<p>A count multiplier for certain elements, such as
<tt>action</tt> or <tt>object</tt>.</p>
</div>
<div class="example">
<pre>
<list>
<object title="frog" count="10"/>
<action title="step3" count="3">
<p>Add 10 ml reagent</p>
</action>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="999999999999"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="summary">General simpleTypes</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType name="idType" id="st.idType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A unique ID for STM elements</div>
<div class="description">
<p>A unique ID for STM elements. This is not formally
of type ID (an XML NAME which must start with a letter and contain only letters,
digits and <tt>.-_:</tt>). It is recommended that IDs start with a letter,
and contain no punctuation or whitespace. The function <tt>generate-id()</tt>
in XSLT will generate semantically void unique IDs</p>.
<p>It is difficult to ensure uniqueness when documents are merged. We suggest
namespacing IDs, perhaps using the containing elements as the base.
Thus <tt>mol3:a1</tt> could be a useful unique ID.
However this is still experimental.</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Za-z0-9_-]+(:[A-Za-z0-9_-]+)?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="userTypeType" id="st.userTypeType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An uncontrolled vocabulary from a user</div>
<div class="description"><p>
An element or attribute representing some part of
an uncontrolled vocabulary. It will be ignored if a <tt>type</tt>
attribute is also set on the element. The <tt>type</tt> attribute
will normally have an enumerated set of values.
</p>
</div>
<div class="example"><pre><alternative type="userType" userType="biological name">SusScrofa</alternative>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
</xsd:restriction>
</xsd:simpleType>
<xsd:attributeGroup name="idGroup" id="attGp.id">
<xsd:attribute id="att.id" name="id" type="idType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A attribute prividing a unique ID for STM elements</div>
<div class="description">
<p>See <a href="st.idType">idType</a> for full documentation.</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:attributeGroup name="titleGroup" id="attGp.title">
<xsd:attribute id="att.title" name="title" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An (optional) title on most STM elements. Uncontrolled</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:attributeGroup name="convGroup" id="attGp.conv">
<xsd:attribute id="att.convention" name="convention" type="namespaceRefType" default="CML">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A reference to a convention</div>
<div class="description">
<p>A reference to a convention which is inherited by all the subelements.</p>
<p>It may be useful to create conventions with namespaces,
</p>
<p>this attribute is inherited by its child elements; thus a <tt>molecule</tt>
with a convention sets the default for its bonds and atoms. This can be overwritten
if necessary by an explicit <tt>convention</tt>.</p>
<p>Use of convention will normally require non-STMML semantics, and should be used with
caution. We would expect that conventions prefixed with "ISO" would be useful,
such as ISO8601 for dateTimes.</p>
</div>
<div class="example">
<pre>
<bond convention="fooChem" order="-5"
xmlns:fooChem="http://www.fooChem/conventions"/>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:annotation>
<xsd:documentation>
<div class="summary">Numeric types</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType name="errorBasisType" id="st.errorBasisType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The basis of an error value</div>
<div class="description">
<p>Errors in values can be of several types and this simpleType
provides a small controlled vocabulary</p>
</div>
<div class="example">
<pre>
<scalar
dataType="xsd:decimal"
errorValue="1.0"
errorBasis="observedStandardDeviation"
title="body weight"
dictRef="zoo:bodywt"
units="units:g">34.3</scalar>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="observedRange"/>
<xsd:enumeration value="observedStandardDeviation"/>
<xsd:enumeration value="observedStandardError"/>
<xsd:enumeration value="estimatedStandardDeviation"/>
<xsd:enumeration value="estimatedStandardError"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="maxType" id="st.maxType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The maximum INCLUSIVE value of a quantity</div>
<div class="description"><p>The maximum INCLUSIVE value of a sortable quantity such as
numeric, date or string. It should be ignored for dataTypes such as URL.
The use of <tt>min</tt> and
<tt>max</tt> attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of <tt>max</tt>
is usually an observed
quantity (or calculated from observations). To restrict a value, the <tt>
maxExclusive</tt> type in a dictionary should be used.</p>
<p>The type of the maximum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</p>
</div>
<div class="example"><pre><scalar dataType="xsd:float" maxValue="20" minValue="12">15</scalar>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="minType" id="st.minType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The minimum INCLUSIVE value of a quantity</div>
<div class="description"><p>The minimum INCLUSIVE value of a sortable quantity such as
numeric, date or string. It should be ignored for dataTypes such as URL.
The use of <tt>min</tt> and
<tt>min</tt> attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of <tt>min</tt>
is usually an observed
quantity (or calculated from observations). To restrict a value, the <tt>
minExclusive</tt> type in a dictionary should be used.</p>
<p>The type of the minimum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</p>
</div>
<div class="example"><pre><scalar dataType="xsd:float" maxValue="20" minValue="12">15</scalar>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
</xsd:restriction>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Links and References</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="link" id="el.link">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An internal or external link to STMML or other object(s)</div>
<div class="description">
<p><tt>link</tt> is an internal or external link to STMML or other object(s). </p>
<p><b>Semantics are similar to XLink, but simpler and only a subset is implemented.</b>
This is intended to make the instances easy to create and read, and software
relatively easy to implement. The architecture is:</p>
<ul>
<li><b>A single element (<tt>link</tt>) used for all linking purposes</b>. </li>
<li><b>The link types are determined by the <tt>type</tt> attribute and can be:</b>.
<ul>
<li><b>locator</b>. This points to a single target and must carry
either a <tt>ref</tt> or <tt>href</tt> attribute.
<tt>locator</tt> links are usually children of an extended link.
<li><b>arc</b>. This is a 1:1 link with both ends (<tt>from</tt> and <tt>to</tt>) defined.</li>
<li><b>extended</b>. This is usually a parent of several locator links and serves
to create a grouping of link ends (i.e. a list of references in documents).</li>
Many-many links can be built up from arcs linking extended elements</li>
</ul>
<p>All links can have optional <tt>role</tt> attributes. The semantics of this are not defined;
you are encouraged to use a URI as described in the XLink specification.</p>
<p>There are two address spaces: </p>
<ul>
<li>The <tt>href</tt> attribute on locators behaves in the same way as <tt>href</tt> in
HTML and is of type <tt>xsd:anyURI</tt>. Its primary use is to use XPointer to reference
elements outside the document.</li>
<li>The <tt>ref</tt> attribute on locators and the <tt>from</tt> and <tt>to</tt>
attributes on <tt>arc</tt>s refer to IDs (<em>without</em> the '#' syntax).</li>
</ul>
<p>Note: several other specific linking mechanisms are defined elsewhere in STM.
<a href="el.relatedEntry">relatedEntry</a>
should be used in dictionaries, and <a href="st.dictRef">dictRef</a>
should be used to link to dictionaries. There are no required uses of <tt>link</tt> in STMML
but we have used it to map atoms, electrons and bonds in reactions in CML</p>
</li>
</ul>
<p><b>Relation to XLink</b>.
At present (2002) we are not aware of generic XLink
processors from which we would benefit, so the complete implementation brings little
extra value.
Among the simplifications from Xlink are:</p>
<ul>
<li><tt>type</tt> supports only <tt>extended</tt>, <tt>locator</tt> and <tt>arc</tt></li>
<li><tt>label</tt> is not supported and <tt>id</tt>s are used as targets of links.</li>
<li><tt>show</tt> and <tt>actuate</tt> are not supported.</li>
<li><tt>xlink:title</tt> is not supported (all STM elements can have a <tt>title</tt>
attribute).</li>
<li><tt>xlink:role</tt> supports any string (i.e. does not have to be a namespaced resource).
This mechanism can, of course, still be used and we shall promote it where STM
benefits from it</li>
<li>The <tt>to</tt> and <tt>from</tt> attributes point to IDs rather than labels</li>
<li>The xlink namespace is not used</li>
<li>It is not intended to create independent linkbases, although some collections of
links may have this property and stand outside the documents they link to</li>
</ul>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="from" type="namespaceRefType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The starting point of an arc</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="to" type="namespaceRefType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The endpoint of an arc</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ref" type="namespaceRefType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An ID referenced within a locator</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="role" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The role of the link. Xlink adds semantics through a
URI; we shall not be this strict. We shall not normally use this mechanism
and use dictionaries instead</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="href" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The target of the (locator) link, outside the document</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="type">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The type of the link</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="extended">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A container for locators</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="locator">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A link to an element</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="arc">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A labelled link</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
<div class="summary">References</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType name="namespaceRefType" id="st.namespaceRefType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
A string referencing a dictionary, units, convention or other metadata.
</div>
<div class="description">
<p>A string referencing a dictionary, units, convention or other
metadata. The namespace is optional but recommended where possible</p>
<p>Note: this convention is only used within STMML and related languages;
it is NOT a URI.</p>
</div>
<div class="example">
<pre>
<list>
<!-- dictRef is of namespaceRefType -->
<scalar dictRef="chem:mpt">123</scalar>
<!-- error -->
<scalar dictRef="mpt23">123</scalar>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="[A-Za-z][A-Za-z0-9_]*(:[A-Za-z][A-Za-z0-9_]*)?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="refType" id="st.refType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A reference to an existing element</div>
<div class="description"><p>A reference to an existing element in the document.
The target of the
ref attribute (which may be namepsaced) must exist. The test for validity
will normally occur in the element's <tt>appinfo</tt>
</p>
<p>Any DOM Node created from this element will normally be a <i>reference</i>
to another Node, so that if the target node is modified a the dereferenced
content is modified. At present there are no deep copy semantics hardcoded
into the schema.</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="idType"/>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="heading">General information components</div>
</xsd:documentation>
</xsd:annotation>
<xsd:annotation>
<xsd:documentation>
<div class="heading">General components</div>
<div class="description">
<p>STMML provides a very small number of abstract elements to capture
frequently encountered concepts in STM documents. There are no predetermined
semantics or ontology; it is expected that descriptive metadata
will be added through dictionaries.
</p>
<p>All elements can contain any element children and can carry the common
STM attributes. Currently there are the following:</p>
<ul>
<li><a href="el.object">object</a>. Almost anything - concrete, abstract, representable by
a noun. Objects can have properties added through <a href="el.scalar">scalar</a>, etc.
</li>
<li><a href="el.action">action</a>. Represents an action performed during a scientific narrative.
It has attributes describing a time-line and conditions so that a procedure could be replayed.
It has a container <a href="el.actionList">actionList</a> which shares these attributes
and which can describe sets of actions.
</li>
<li><a href="el.observation">observation</a>. Contains narrative or other elements describing
an observation, planned or unplanned</li>
</ul>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="action" id="el.action">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An action which might occur in scientific data or narrative.</div>
<div class="description">
<p>An action which might occur in scientific data or narrative.
The definition is deliberately vague, intending to collect examples of
possible usage. Thus an action could be addition of materials,
measurement, application of heat or radiation.
The content model is unrestricted. <tt>action</tt> iself is
normally a child of <a href="#el.actionList">actionList</a></p>
<p>The start, end and duration attributes should be interpreted as
</p>
<ul>
<li>XSD dateTimes and XSD durations. This allows precise recording of
time of day, etc, or duration
after start of actionList. A <tt>convention="xsd"</tt> attribute should be used
to enforce XSD.</li>
<li>a numerical value, with a units attribute linked to a dictionary.</li>
<li>a human-readable string (unlikely to be machine processable)</li>
</ul>
<p>
<tt>startCondition</tt> and <tt>endCondition</tt>
values are not constrained, which allows XSL-like <tt>test</tt> attribute values.
The semantics of the conditions are yet to be defined and at present are simply
human readable.
</p>
<p>The order of the <tt>action</tt> elements in the document may,
but will not always, define the order that they actually occur in.</p>
<p>A delay can be shown by an <tt>action</tt> with no content. Repeated actions or
actionLists are indicated through the count attribute.</p>
</div>
<div class="example">
<pre>
<actionList title="boiling two eggs for breakfast">
<!-- start cooking at 9am -->
<action title="turn on heat" start="T09:00:00" convention="xsd"/>
<!-- human readable description of time to start action -->
<action title="put egg into pan" startCondition="water is boiling" count="2"/>
<!-- the duration is expressed in ISO8601 format -->
<action title="boil eggs for 4 minutes" duration="4" units="units:min"/>
<!-- action immediately follows last action -->
<action title="remove egg from pan" count="1"/>
<action title="boil second egg for a bit longer" duration="about half a minute"/>
<!-- action immediately follows last action -->
<action title="remove egg from pan" count="1"/>
</actionList>
</pre>
</div>
<div class="example">
<pre>
<actionList title="preparation of silanols">
<p>This is a conversion of a chemical synthesis to STMML. We
have deliberately not marked up the chemistry in this example!</p>
<action title="step2">
<p>Take 1 mmol of the diol and dissolve in dioxan in
<object title="flask">
<scalar title="volume" units="units:ml">25</scalar>
</object>
</p>
</action>
<action title="step2">
<p>Place flask in water bath with magnetic stirrer</p>
</action>
<!-- wait until certain condition -->
<actionList endCondition="bath temperature stabilised"/>
<action title="step3">
<p>Add 0.5 ml 1 M H2SO4</p>
</action>
<!-- carry out reaction -->
<actionList endCondition="reaction complete; no diol spot remains on TLC">
<actionList title="check tlc">
<!-- wait for half an hour -->
<action duration="half an hour"/>
<action title="tlc">
<p>extract solution and check diol spot on TLC</p>
</action>
</actionList>
</actionList>
<!-- work up reaction -->
<action title="step5">
<p>Add 10 ml water to flask</p>
</action>
<action title="step6">
<p>Neutralize acid with 10% NaHCO3</p>
</action>
<action title="step7" count="3">
<p>Extract with 10ml ether</p>
</action>
<action title="step8">
<p>Combine ether layers</p>
</action>
<action title="step9" count="2">
<p>Wash ether with 10 ml water</p>
</action>
<action title="step10">
<p>Wash ether with 10 ml saturated NaCl</p>
</action>
<action title="step11">
<p>Dry over anhydrous Na2SO4 and remove solvent on rotary evaporator</p>
</action>
</actionList>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attributeGroup ref="actionGroup"/>
<xsd:attribute name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The type of the action; semantics are not controlled.</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="actionList" id="el.actionList">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A container for a group of <a href="el.action">actions</a></div>
<div class="description">
<p><tt>ActionList</tt> contains a series of <tt>action</tt>s or
nested <tt>actionList</tt>s.</p>
</div>
<div class="example">See examples in <a href="el.action">action</a></div>
<div class="example">
<pre>
<!-- demonstrating parallel and sequential actions -->
<actionList order="parallel" endCondition="all food cooked">
<!-- meat and potatoes are cooked in parallel -->
<actionList title="meat">
<action title="cook" endCondition="cooked">
<p>Roast meat</p>
</action>
<action><p>Keep warm in oven</p></action>
</actionList>
<actionList title="vegetables">
<actionList title="cookVeg" endCondition="cooked">
<action title="boil water" endCondition="water boiling">
<p>Heat water</p>
</action>
<action title="cook" endCondition="potatoes cooked">
<p>Cook potatoes</p>
</action>
</actionList>
<action><p>Keep warm in oven</p></action>
</actionList>
</actionList>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attributeGroup ref="actionGroup"/>
<xsd:attribute name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The type of the actionList; no defined semantics</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="order" default="sequential">
<xsd:annotation>
<xsd:documentation>
<div class="description">Describes whether child elements are sequential or parallel</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="sequential"/>
<xsd:enumeration value="parallel"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="object" id="el.object">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An object which might occur in scientific data or narrative</div>
<div class="description"><p>Deliberately vague.
Thus an instrument might be built from sub component
objects, or a program could be composed of smaller modules (objects).
Unrestricted content model</p>
</div>
<div class="example"><pre><object title="frog" type="amphibian" count="5">
<scalar dataType="xsd:float" title="length" units="unit:cm">5</scalar>
</object>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Type of the object. Uncontrolled semantics</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="count" type="countType"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="observation" id="el.observation">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An observation or occurrence</div>
<div class="description"><p>A container for any events that
need to be recorded, whether planned or not. They can include notes,
measurements, conditions that may be referenced elsewhere, etc. There are
no controlled semantics </p>
<div class="example"><pre><observation type="ornithology">
<object title="sparrow" count="3"/>
</observation>
</pre></div>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="type" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Type of observation (uncontrolled vocabulary)</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="count" type="countType"/>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Dictionary components</div>
<div class="description">
<p>Dictionaries are a major part of STMML and supported as follows:</p>
<p>The dictionary itself:</p>
<ul>
<li><a href="el.dictionary">dictionary</a>. This element defines a dictionary
and is often the root element (though a data instance might also be combined
with a dictionary). The dictionary play a similar role to a simple schema, by defining
data types and other constraints (such as enumerations). By transforming a dictionary to
schema format, schema-based tools can be used for validation. A dictionary is
normally composed of <a href="el.entry">entry</a>s.</li>
<li><a href="el.entry">entry</a>. An entry contanins information which <em>describes</em>
or <em>constrains</em> elements in a data instance. The link is made through a
<a href="st.dictRef">dictRef</a> attribute on the data element.
Descriptive information can apply to any type of element (not necessarily
part of or derived from the STM Schema). Constraints are similar to those in XML Schemas
and use the same vocabulary (dataTypes, value ranges, enumerations, patterns, etc.). They normally
apply to elements from the STM Schema or derived from it.<br/>
In addition entrys can constrain elements to have the same
higher-level structures and constraints defined by STM Schema. Thus entrys can require a
data element to be a matrix, of a given type, with fixed number os rows and columns. These
constraints are usually attributes on the entry element, which therefore maps
directly onto the instance. Every entry has a mandatory <tt>term</tt> attribute
which is the formal text string representing the concept. This string can contain any allowed
XML characters (e.g. greek characters) but not markup (e.g. MathML or CML).</li>
<li><a href="el.definition">definition</a>. An almost mandatory child element of entry, giving
a formal definition of the term</li>
<li><a href="el.description">description</a>. Additional
descriptive informati>on for an entry.
This can contain any content, often HTML, but also MathML, CML for description of
equations, chemical formulae, etc.</li>
<li><a href="el.alternative">alternative</a>. Alternative strings for describing the
concept. These can be any of the stnadard lexical and terminological data categories
such as synonyms, abbreviations, homonyms, etc. (see ISO12620 for a full range).</li>
<li><a href="el.enumeration">enumeration</a>. A list of allowed values for the data
element (or elements in arrays, matrices).</li>
<li><a href="el.relatedEntry">relatedEntry</a>. A related entry. Sometimes this is
descriptive (e.g. "seeAlso" provides additional information on related concepts).
It can also be used for constraints, and there is a small controlled vocabulary
of relationships, but no universal syntax. We
support parentage (e.g. through "partitiveParent" = "partOf"). In principle this can
be used with <a href="el.appinfo">appinfo</a> to provide algorithmically constructed
relationships.
</li>
<li><em>attributes</em>. A wide range of constraints is provided through attributes,
several being similar to facets on XML Schema datatypes:
<ul>
<li><b>rows</b> and <b>columns</b>, the structure of the data element.</li>
<li><b>recommendedUnits</b>, <b>units</b> and <b>unitType</b>,
the units of the data element.</li>
<li><b>minExclusive</b>, <b>minInclusive</b>, <b>maxExclusive</b>
and <b>maxInclusive</b>,
the value of the data element.</li>
<li><b>totalDigits</b>, <b>fractionDigits</b>, <b>length</b>,
<b>maxLength</b>, <b>minLength</b>
and <b>pattern</b>. The lexical form of the data element.</li>
</ul>
</li>
<li><a href="el.annotation">annotation</a>. Similar to XML Schema, this has children
<a href="el.documentation">documentation</a> for information about the entry (normally
curatorial) and <a href="el.appinfo">appinfo</a> to describe entries and constraints
in machine-processable fashion.
.</li>
</ul>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="dictionary" id="el.dictionary">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A dictionary</div>
<div class="description">
<p>A dictionary is a container for <a href="el.entry">entry</a>
elements. Dictionaries can also contain unit-related information.</p>
<p>The dictRef attribute on a <tt>dictionary</tt> element
sets a namespace-like prefix allowing the dictionary to be referenced from
within the document. In general dictionaries are
referenced from an element using the
<a href="gp.dictRefGroup">dictRef</a> attribute.</p>
</div>
<div class="example">
<pre>
<stm:dictionary xmlns:stm="http://www.xml-cml.org/schema/stmml">
<stm:entry id="a001" term="Amplitude for charge density mixing"
dataType="stm:decimal"
units="arbitrary">
<stm:annotation>
<stm:documentation>
<div class="summary">Amplitude for charge density mixing</div>
<div class="description">Not yet filled in...</div>
</stm:documentation>
</stm:annotation>
<stm:alternative type="abbreviation">CDMixAmp</stm:alternative>
</stm:entry>
</stm:dictionary>
</pre>
</div>
<div class="example">
<p><tt>dictionary</tt> can be used in an instance
document to reference the dictionary used. Example:</p>
<pre>
<list>
<dictionary
dictRef="core" href="../dictionary/coreDict.xml"/>
<!-- ... -->
<scalar dictRef="core:frog" title="specimens">Frogs</scalar>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="unitList" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
<div class="description"><p>This is so that a reference to a UnitList can be put in a dictionary.</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element ref="annotation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="description" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="entry" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="href" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
<div class="summary">URI giving the location of the document. Mandatory if <tt>dictRef</tt>
present.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="entry" id="el.entry">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A dictionary entry</div>
<div class="example">
<pre>
<s:entry id="a003" term="alpha"
dataType="float"
minInclusive="0.0"
maxInclusive="180.0"
recommendedUnits="degrees"
xmlns:s="http://www.xml-cml.org/schema/stmml">
<s:definition>The alpha cell angle</s:definition>
</s:entry>
</pre>
</div>
<div class="example">
<pre>
<entry id="a003"
term="matrix1"
dataType="float"
rows="3"
columns="4"
unitType="unit:length"
minInclusive="0.0"
maxInclusive="100.0"
recommendedUnits="unit:m"
totalDigits="8"
fractionDigits="3">
<definition>A matrix of lengths</definition>
<description>A data instance will have a matrix which points
to this entry (e.g. dictRef="foo:matrix1"). The matrix must
be 3*4, composed of floats in 8.3 format, of type length,
values between 0 and 100 and with recommended units metres.
</description>
</entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="definition" minOccurs="0"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="alternative"/>
<xsd:element ref="annotation"/>
<xsd:element ref="definition"/>
<xsd:element ref="description"/>
<xsd:element ref="enumeration"/>
<xsd:element ref="relatedEntry"/>
</xsd:choice>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_convGroup"/>
<xsd:attribute name="dataType" type="xsd:string"/>
<xsd:attribute name="rows" type="xsd:positiveInteger" default="1"/>
<xsd:attribute name="columns" type="xsd:positiveInteger" default="1"/>
<xsd:attribute name="recommendedUnits" type="unitsType"/>
<xsd:attribute name="unitType" type="xsd:string"/>
<xsd:attribute name="minExclusive" type="xsd:decimal"/>
<xsd:attribute name="minInclusive" type="xsd:decimal"/>
<xsd:attribute name="maxExclusive" type="xsd:decimal"/>
<xsd:attribute name="maxInclusive" type="xsd:decimal"/>
<xsd:attribute name="totalDigits" type="xsd:positiveInteger"/>
<xsd:attribute name="fractionDigits" type="xsd:nonNegativeInteger"/>
<xsd:attribute name="length" type="xsd:nonNegativeInteger"/>
<xsd:attribute name="minLength" type="xsd:nonNegativeInteger"/>
<xsd:attribute name="maxLength" type="xsd:positiveInteger"/>
<xsd:attribute name="units" type="unitsType"/>
<xsd:attribute name="whiteSpace" type="xsd:string"/>
<xsd:attribute name="pattern" type="xsd:string"/>
<xsd:attribute name="term" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="definition" id="el.definition">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>The definition for a dictionary entry, scientific units, etc.</p>
</div>
<div class="description">
<p>The definition should be a short nounal phrase definining the
subject of the entry. Definitions should not include commentary, implementations,
equations or formulae (unless the subject is one of these) or examples. The
<tt>description</tt> element can be used for these.</p>
<p>The definition can be in any markup language, but normally XHTML will be used,
perhaps with links to other XML namespaces such as CML for chemistry.</p>
</div>
<div class="example">
<em>From the IUPAC Dictionary of Medicinal Chemistry</em><br/>
<pre>
<entry id="a7" term="Allosteric enzyme">
<definition>An <a href="#e3">enzyme</a>
that contains a region to which small, regulatory molecules
("effectors") may bind in addition to and separate from the
substrate binding site and thereby affect the catalytic
activity.
</definition>
<description>On binding the effector, the catalytic activity of the
<strong>enzyme</strong> towards the substrate may be enhanced, in
which case the effector is an activator, or reduced, in which case
it is a de-activator or inhibitor.
</description>
</entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="sourceGroup"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="description" id="el.description">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Descriptive information in a dictionary entry, etc.</div>
<div class="description">
<p>Entries should have at least one separate <a href="el.definition">definition</a>s.
<tt>description</tt> is then used for most of the other information, including
examples. The <tt>class</tt> attribute has an uncontrolled vocabulary and
can be used to clarify the purposes of the <tt>description</tt>
elements.</p>
</div>
<div class="example">
<em>From IUPAC Dictionary of Medicinal Chemistry</em>
<pre>
<entry id="a7" term="Allosteric enzyme">
<definition>An <a href="#e3">enzyme</a>
that contains a region to which small, regulatory molecules
("effectors") may bind in addition to and separate from the
substrate binding site and thereby affect the catalytic
activity.
</definition>
<description>On binding the effector, the catalytic activity of the
<strong>enzyme</strong> towards the substrate may be enhanced, in
which case the effector is an activator, or reduced, in which case
it is a de-activator or inhibitor.
</description>
</entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="sourceGroup"/>
<xsd:attribute name="class" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="description"><p>The type of this information. This is not controlled, but examples
might include:</p>
<ul>
<li>description</li>
<li>summary</li>
<li>note</li>
<li>usage</li>
<li>qualifier</li>
</ul>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="enumeration" id="el.enumeration">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An enumeration of string values associated
with an <a href="el.entry">entry</a></div>
<div class="description">
<p>An enumeration of string values. Used where a dictionary entry constrains
the possible values in a document instance. The dataTypes (if any) must all be
identical and are defined by the dataType of the containing element.</p>
</div>
<div class="example">
<pre>
<entry term="crystal system" id="cryst1" dataType="string">
<definition>A crystal system</definition>
<enumeration value="triclinic">
<annotation>
<documentation>
<div class="summary">No constraints on lengths and angles</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="monoclinic">
<annotation>
<documentation>
<div class="summary">Two cell angles are right angles; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="orthorhombic">
<annotation>
<documentation>
<div class="summary">All three angles are right angles; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="tetragonal">
<annotation>
<documentation>
<div class="summary">Fourfold axis of symmetry; All three angles are right angles; two equal cell lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="trigonal">
<annotation>
<documentation>
<div class="summary">Threefold axis of symmetry; Two angles are right angles; one is 120 degrees; two equal lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="hexagonal">
<annotation>
<documentation>
<div class="summary">Sixfold axis of symmetry; Two angles are right angles; one is 120 degrees; two equal lengths; no other constraints</div>
</documentation>
</annotation>
</enumeration>
<enumeration value="cubic">
<annotation>
<documentation>
<div class="summary">All three angles are right angles; all cell lengths are equal</div>
</documentation>
</annotation>
</enumeration>
</entry>
</pre>
</div>
<div class="description">
<p>An enumeration of string values. The dataTypes (if any) must all be
identical and are defined by the dataType of the containing element.</p>
<p>Documentation can be added through an <a href="el.enumeration">enumeration</a>
child</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="annotation" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The value of the enumerated element.</div>
<div class="description">
Must be compatible
with the dataType of the containing element (not schema-checkable directly
but possible if dictionary is transformed to schema).</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="alternative" id="el.alternative">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>An alternative name for an entry</p>
</div>
<div class="description">
<p>At present a child of <a href="#el.entry">entry</a> which represents
an alternative string that refers to the concept. There is a partial controlled
vocabulary in <tt>alternativeType</tt> with values such as :
</p>
<ul>
<li>synonym</li>
<li>acronym</li>
<li>abbreviation</li>
</ul>
</div>
<div class="example">
<pre>
<entry term="ammonia" id="a1">
<alternative type="synonym">Spirits of hartshorn</alternative>
</entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:attribute name="type" default="userType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">the type of an
<a href="#el.alternative">alternative</a> element.</div>
<div class="description">
<p>
<tt>alternativeType</tt> represents a the type of an
<a href="#el.alternative">alternative</a> element.
</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="synonym"/>
<xsd:enumeration value="quasi-synonym"/>
<xsd:enumeration value="acronym"/>
<xsd:enumeration value="abbreviation"/>
<xsd:enumeration value="homonym"/>
<xsd:enumeration value="identifier"/>
<xsd:enumeration value="userType"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="userType" type="userTypeType"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="relatedEntry" id="el.relatedEntry">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An entry related in some way to a dictionary entry, scientific units, etc.</div>
<div class="description"><p>The range of relationships is not restricted
but should include parents, aggregation, seeAlso
etc. dataCategories from ISO12620 can be referenced through the <tt>userType</tt>
attribute.</p></div>
<div class="example">
<pre>
<stm:entry id="a14" term="Autoreceptor"
xmlns:stm="http://www.xml-cml.org/schema/core">
<stm:definition>An <strong>autoreceptor</strong>, present at a nerve ending, is
a <a href="#r1">receptor</a>
that regulates, via positive or negative feedback processes, the
synthesis and/or release of its own physiological ligand.
</stm:definition>
<stm:relatedEntry type="seeAlso" href="#h4">Heteroreceptor).</stm:relatedEntry>
</stm:entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:attribute name="type" default="userType">
<xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="description"><p>
<tt>relatedEntryType</tt> represents a the type of relationship in a
<a href="#el.relatedEntry">relatedEntry</a> element.
</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="parent"/>
<xsd:enumeration value="partitiveParent"/>
<xsd:enumeration value="child"/>
<xsd:enumeration value="partitiveChild"/>
<xsd:enumeration value="related"/>
<xsd:enumeration value="synonym"/>
<xsd:enumeration value="quasi-synonym"/>
<xsd:enumeration value="antonym"/>
<xsd:enumeration value="homonym"/>
<xsd:enumeration value="see"/>
<xsd:enumeration value="seeAlso"/>
<xsd:enumeration value="abbreviation"/>
<xsd:enumeration value="acronym"/>
<xsd:enumeration value="userType"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="userType" type="userTypeType"/>
<xsd:attribute name="href" type="xsd:anyURI"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="annotation" id="el.annotation">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>A documentation container similar to <tt>annotation</tt> in XML Schema.</p>
</div>
<div class="description"> <p>A documentation container similar to <tt>annotation</tt> in XML Schema.
At present this is experimental and designed to be used for dictionaries, units, etc.
One approach is to convert these into XML Schemas when the <tt>documentation</tt>
and <tt>appinfo</tt> children will emerge in their correct position in the
derived schema.</p>
<p>It is possible that this may develop as a useful tool for annotating components
of complex objects such as molecules. </p>
</div>
<div class="example">
<pre>
<entry term="matrix">
<annotation>
<documentation>This refers to mathematical matrices</documentation>
<appinfo>... some code to describe and support matrices ...</appinfo>
</annotation>
</entry>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="documentation"/>
<xsd:element ref="appinfo"/>
</xsd:choice>
<xsd:attribute name="source" type="xsd:anyURI"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="documentation" id="el.documentation">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Documentation in the <a href="el.annotation">annotation</a> of an <a href="el.entry">entry</a></div>
<div class="description">
<p>A container similar to <tt>documentation</tt> in XML Schema.
This is NOT part of the textual content of an entry but is designed to
support the transformation of dictionary entrys into schemas for validation.
This is experimental and should only be used for dictionaries, units, etc.
One approach is to convert these into XML Schemas when the <tt>documentation</tt>
and <tt>appinfo</tt> children will emerge in their correct position in the
derived schema.</p>
<p>Do NOT confuse documentation with the <a href="el.definition">definition</a>
or the <a href="el.definition">definition</a> which are part of the content
of the dictionary</p>
<p>If will probably only be used when there is significant <a href="el.appinfo">appinfo</a>
in the entry or where the entry defines an XSD-like datatype of an element in the document.</p>
</div>
<div class="example">
<pre>
<stm:documentation id="source"
xmlns:stm="http://www.xml-cml.org/schema/stmml">
Transcribed from IUPAC website
</stm:documentation>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attributeGroup ref="sourceGroup"/>
<xsd:attributeGroup ref="idGroup"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="appinfo" id="el.appinfo">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>A container similar to <tt>appinfo</tt> in XML Schema.</p>
</div>
<div class="description">
<p>A container for machine processable documentation for an entry.
This is likely to be platform and/or language specific. It is possible
that XSLT, RDF or XBL will emerge as generic languages</p>
<p>See <a href="el.annotation">annotation</a> and <a href="el.documentation">documentation</a> for further information</p>
</div>
<div class="example">
<p>An example in XSLT where an element <tt>foo</tt> calls a bespoke
template</p>.
<pre>
<s:appinfo
xmlns:s="http://www.xml-cml.org/schema/core"
xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="foo">
<call-template name="processFoo"/>
</template>
</s:appinfo>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType mixed="true">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:any processContents="lax"/>
</xsd:sequence>
<xsd:attribute name="source" type="xsd:anyURI"/>
</xsd:complexType>
</xsd:element>
<xsd:attributeGroup name="dictRefGroup" id="attGp.dictRefGroup">
<xsd:attribute id="att.dictRef" name="dictRef" type="namespaceRefType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>A reference to a dictionary entry.</p>
</div>
<div class="description">
<p>Elements in data instances such as <a href="el.scalar">scalar</a> may have a
<tt>dictRef</tt> attribute to point to an entry in a dictionary. To avoid
excessive use of (mutable) filenames and URIs we recommend a namespace
prefix, mapped to a namespace URI in the normal manner. In this case,
of course, the namespace URI must point to a real XML document containing
<a href="el.entry">entry</a> elements and validated against STMML Schema.</p>
<p>Where there is concern about the dictionary becoming separated from the document
the dictionary entries can be physically included as part of the data instance
and the normal XPointer addressing mechanism can be used.</p>
<p>This attribute can also be used on <a href="el.dictionary">dictionary</a>
elements to define the namespace prefix</p>
</div>
<div class="example">
<pre>
<scalar dataType="xsd:float" title="surfaceArea"
dictRef="cmlPhys:surfArea"
xmlns:cmlPhys="http://www.xml-cml.org/dict/physical"
units="units:cm2">50</scalar>
</pre>
</div>
<div class="example">
<pre>
<stm:list xmlns:stm="http://www.xml-cml.org/schema/stmml">
<stm:observation>
<p>We observed <object count="3" dictRef="#p1"/>
constructing dwellings of different material</p>
</stm:observation>
<stm:entry id="p1" term="pig">
<stm:definition>A domesticated animal.</stm:definition>
<stm:description>Predators include wolves</stm:description>
<stm:description class="scientificName">Sus scrofa</stm:description>
</stm:entry>
</stm:list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:annotation>
<xsd:documentation>
<div class="subheading">Metadata</div>
<div class="description">
<p>STMML supports metadata through the element
<a href="el.metadata">metadata</a>. If necessary
several of these can be contained in
a <a href="el.metadataList">metadataList</a> element.
</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="metadata" id="el.metadata">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A general container for metadata</div>
<div class="description"><p>A general container for metadata, including at least
Dublin Core (DC) and CML-specific metadata</p>
<p>In its simple form each element provides a name and content in a similar
fashion to the <tt>meta</tt> element in HTML. <tt>metadata</tt> may have simpleContent
(i.e. a string for adding further information - this is not controlled).</p>
</div>
<div class="example"><pre>
<list>
<metadataList>
<metadata name="dc:coverage" content="Europe"/>
<metadata name="dc:description" content="Ornithological chemistry"/>
<metadata name="dc:identifier" content="ISBN:1234-5678"/>
<metadata name="dc:format" content="printed"/>
<metadata name="dc:relation" content="abc:def123"/>
<metadata name="dc:rights" content="licence:GPL"/>
<metadata name="dc:subject" content="Informatics"/>
<metadata name="dc:title" content="birds"/>
<metadata name="dc:type" content="bird books on chemistry"/>
<metadata name="dc:contributor" content="Tux Penguin"/>
<metadata name="dc:creator" content="author"/>
<metadata name="dc:publisher" content="Penguinone publishing"/>
<metadata name="dc:source" content="penguinPub"/>
<metadata name="dc:language" content="en-GB"/>
<metadata name="dc:date" content="1752-09-10"/>
</metadataList>
<metadataList>
<metadata name="cmlm:safety" content="mostly harmless"/>
<metadata name="cmlm:insilico" content="electronically produced"/>
<metadata name="cmlm:structure" content="penguinone"/>
<metadata name="cmlm:reaction" content="synthesis of penguinone"/>
<metadata name="cmlm:identifier" content="smiles:O=C1C=C(C)C(C)(C)C(C)=C1"/>
</metadataList>
</list>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" type="metadataType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The metadata type</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="content" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The metadata</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="metadataList" id="el.metadataList">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A general container for metadata elements</div>
<div class="example"><pre><list>
<metadataList>
<metadata name="dc:coverage" content="Europe"/>
<metadata name="dc:description" content="Ornithological chemistry"/>
<metadata name="dc:identifier" content="ISBN:1234-5678"/>
<metadata name="dc:format" content="printed"/>
<metadata name="dc:relation" content="abc:def123"/>
<metadata name="dc:rights" content="licence:GPL"/>
<metadata name="dc:subject" content="Informatics"/>
<metadata name="dc:title" content="birds"/>
<metadata name="dc:type" content="bird books on chemistry"/>
<metadata name="dc:contributor" content="Tux Penguin"/>
<metadata name="dc:creator" content="author"/>
<metadata name="dc:publisher" content="Penguinone publishing"/>
<metadata name="dc:source" content="penguinPub"/>
<metadata name="dc:language" content="en-GB"/>
<metadata name="dc:date" content="1752-09-10"/>
</metadataList>
<metadataList>
<metadata name="cmlm:safety" content="mostly harmless"/>
<metadata name="cmlm:insilico" content="electronically produced"/>
<metadata name="cmlm:structure" content="penguinone"/>
<metadata name="cmlm:reaction" content="synthesis of penguinone"/>
<metadata name="cmlm:identifier" content="smiles:O=C1C=C(C)C(C)(C)C(C)=C1"/>
</metadataList>
</list>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="metadata" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="metadataType" id="md.metadataType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="dc:coverage">
<xsd:annotation>
<xsd:documentation>
<div class="definition">The extent or scope of the
content of the resource.</div>
<div class="description">Coverage will typically include
spatial location (a place name or geographic
coordinates), temporal period (a period label, date, or
date range) or jurisdiction (such as a named
administrative entity). Recommended best practice is to
select a value from a controlled vocabulary (for
example, the Thesaurus of Geographic Names [TGN]) and
that, where appropriate, named places or time periods
be used in preference to numeric identifiers such as
sets of coordinates or date ranges.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:description">
<xsd:annotation>
<xsd:documentation>
<div class="definition">An account of the content of the
resource.</div>
<div class="description">Description may include but is not
limited to: an abstract, table of contents, reference
to a graphical representation of content or a free-text
account of the content.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:identifier">
<xsd:annotation>
<xsd:documentation>
<div class="definition">An unambiguous reference to the
resource within a given context.</div>
<div class="description">Recommended best practice is to
identify the resource by means of a string or number
conforming to a formal identification system. Example
formal identification systems include the Uniform
Resource Identifier (URI) (including the Uniform
Resource Locator (URL)), the Digital Object Identifier
(DOI) and the International Standard Book Number
(ISBN).
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:format">
<xsd:annotation>
<xsd:documentation>
<div class="definition">The physical or digital
manifestation of the resource.</div>
<div class="description">Typically, Format may include the
media-type or dimensions of the resource. Format may be
used to determine the software, hardware or other
equipment needed to display or operate the resource.
Examples of dimensions include size and duration.
Recommended best practice is to select a value from a
controlled vocabulary (for example, the list of
Internet Media Types [MIME] defining computer media
formats).
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:relation">
<xsd:annotation>
<xsd:documentation>
<div class="definition">A reference to a related
resource.</div>
<div class="description">Recommended best practice is to
reference the resource by means of a string or number
conforming to a formal identification system.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:rights">
<xsd:annotation>
<xsd:documentation>
<div class="definition">Information about rights held in
and over the resource.</div>
<div class="description">Typically, a Rights element will
contain a rights management statement for the resource,
or reference a service providing such information.
Rights information often encompasses Intellectual
Property Rights (IPR), Copyright, and various Property
Rights. If the Rights element is absent, no assumptions
can be made about the status of these and other rights
with respect to the resource.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:subject">
<xsd:annotation>
<xsd:documentation>
<div class="definition">The topic of the content of the
resource.</div>
<div class="description">Typically, a Subject will be
expressed as keywords, key phrases or classification
codes that describe a topic of the resource.
Recommended best practice is to select a value from a
controlled vocabulary or formal classification
scheme.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:title">
<xsd:annotation>
<xsd:documentation>
<div class="definition">A name given to the resource.</div>
<div class="description">Typically, a Title will be a name by
which the resource is formally known.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:type">
<xsd:annotation>
<xsd:documentation>
<div class="definition">The nature or genre of the
content of the resource.</div>
<div class="description">Type includes terms describing
general categories, functions, genres, or aggregation
levels for content. Recommended best practice is to
select a value from a controlled vocabulary (for
example, the working draft list of Dublin Core Types
[DCT1]). To describe the physical or digital
manifestation of the resource, use the FORMAT
element.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:contributor">
<xsd:annotation>
<xsd:documentation>
<div class="definition">An entity responsible for making
contributions to the content of the resource.</div>
<div class="description">Examples of a Contributor include a
person, an organisation, or a service. Typically, the
name of a Contributor should be used to indicate the
entity.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:creator">
<xsd:annotation>
<xsd:documentation>
<div class="definition">An entity primarily responsible
for making the content of the resource.</div>
<div class="description">Examples of a Creator include a
person, an organisation, or a service. Typically, the
name of a Creator should be used to indicate the
entity.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:publisher">
<xsd:annotation>
<xsd:documentation>
<div class="definition">An entity responsible for making
the resource available</div>
<div class="description">Examples of a Publisher include a
person, an organisation, or a service. Typically, the
name of a Publisher should be used to indicate the
entity.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:source">
<xsd:annotation>
<xsd:documentation>
<div class="definition">A Reference to a resource from
which the present resource is derived.</div>
<div class="description">The present resource may be derived
from the Source resource in whole or in part.
Recommended best practice is to reference the resource
by means of a string or number conforming to a formal
identification system.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:language">
<xsd:annotation>
<xsd:documentation>
<div class="definition">A language of the intellectual
content of the resource.</div>
<div class="description">Recommended best practice for the
values of the Language element is defined by RFC 1766
[RFC1766] which includes a two-letter Language Code
(taken from the ISO 639 standard [ISO639]), followed
optionally, by a two-letter Country Code (taken from
the ISO 3166 standard [ISO3166]). For example, 'en' for
English, 'fr' for French, or 'en-uk' for English used
in the United Kingdom.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="dc:date">
<xsd:annotation>
<xsd:documentation>
<div class="definition">A date associated with an event
in the life cycle of the resource.</div>
<div class="description">Typically, Date will be associated
with the creation or availability of the resource.
Recommended best practice for encoding the date value
is defined in a profile of ISO 8601 [W3CDTF] and
follows the YYYY-MM-DD format.
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="cmlm:safety">
<xsd:annotation>
<xsd:documentation>
<div class="definition">Entry contains information
relating to chemical safety</div>
<div class="description">Typically the content will be a
reference to a handbook, MSDS, threshhold or other
human-readable string
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="cmlm:insilico">
<xsd:annotation>
<xsd:documentation>
<div class="definition">Part or whole of the information
was computer-generated</div>
<div class="description">Typically the content will be the
name of a method or a program
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="cmlm:structure">
<h2>structure</h2>
<xsd:annotation>
<xsd:documentation>
<div class="definition">3D structure included</div>
<div class="description">details included
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="cmlm:reaction">
</xsd:enumeration>
<xsd:enumeration value="cmlm:identifier">
</xsd:enumeration>
<xsd:enumeration value="other">
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="heading">Scientific Units</div>
</xsd:documentation>
</xsd:annotation>
<xsd:element name="dimension" id="el.dimension">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A dimension supporting scientific units</div>
<div class="description">
<p>This will be primarily used within the defintion of
<a href="el.unit">units</a>s.</p>
</div>
<div class="example">
<pre>
<unitType id="energy" name="energy">
<dimension name="length"/>
<dimension name="mass"/>
<dimension name="time" power="-1"/>
</unitType>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
<xsd:attribute name="name" type="dimensionType" use="required">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The type of the dimension</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="power" type="xsd:decimal" default="1">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The power to which the dimension should be raised</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="dimensionType" id="st.dimensionType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Allowed values for dimension Types (for quantities).</div>
<div class="description">
<p>These are the 7 types prescribed by the SI system, together
with the "dimensionless" type. We intend to be somewhat uncoventional
and explore enhanced values of "dimensionless", such as "angle".
This may be heretical, but we find the present system impossible to implement
in many cases.</p>
<p>Used for constructing entries in a dictionary of units</p>
</div>
<div class="example">
<pre>
<unitType id="energy" name="energy">
<dimension name="length"/>
<dimension name="mass"/>
<dimension name="time" power="-1"/>
</unitType>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="mass"/>
<xsd:enumeration value="length"/>
<xsd:enumeration value="time"/>
<xsd:enumeration value="charge"/>
<xsd:enumeration value="amount"/>
<xsd:enumeration value="luminosity"/>
<xsd:enumeration value="temperature"/>
<xsd:enumeration value="dimensionless"/>
<xsd:enumeration value="angle">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An angle (formally dimensionless, but useful to have units).</div>
</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="unitList" id="el.unitList">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A container for several unit entries</div>
<div class="description">Usually forms the complete units dictionary (along with metadata)</div>
<div class="example"><pre><stm:unitList xmlns:stm="http://www.xml-cml.org/schema/stmml">
<!-- ======================================================================= -->
<!-- ========================= fundamental types =========================== -->
<!-- ======================================================================= -->
<stm:unitType id="length" name="length">
<stm:dimension name="length"/>
</stm:unitType>
<stm:unitType id="time" name="time">
<stm:dimension name="time"/>
</stm:unitType>
<!-- ... -->
<stm:unitType id="dimensionless" name="dimensionless">
<stm:dimension name="dimensionless"/>
</stm:unitType>
<!-- ======================================================================= -->
<!-- ========================== derived types ============================== -->
<!-- ======================================================================= -->
<stm:unitType id="acceleration" name="acceleration">
<stm:dimension name="length"/>
<stm:dimension name="time" power="-2"/>
</stm:unitType>
<!-- ... -->
<!-- ======================================================================= -->
<!-- ====================== fundamental SI units =========================== -->
<!-- ======================================================================= -->
<stm:unit id="second" name="second" unitType="time">
<stm:description>The SI unit of time</stm:description>
</stm:unit>
<stm:unit id="meter" name="meter" unitType="length"
abbreviation="m">
<stm:description>The SI unit of length</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="kg" name="nameless" unitType="dimensionless"
abbreviation="nodim">
<stm:description>A fictitious parent for dimensionless units</stm:description>
</stm:unit>
<!-- ======================================================================= -->
<!-- ===================== derived SI units ================================ -->
<!-- ======================================================================= -->
<stm:unit id="newton" name="newton" unitType="force">
<stm:description>The SI unit of force</stm:description>
</stm:unit>
<!-- ... -->
<!-- multiples of fundamental SI units -->
<stm:unit id="g" name="gram" unitType="mass"
parentSI="kg"
multiplierToSI="0.001"
abbreviation="g">
<stm:description>0.001 kg. </stm:description>
</stm:unit>
<stm:unit id="celsius" name="Celsius" parentSI="k"
multiplierToSI="1"
constantToSI="273.18">
<stm:description><p>A common unit of temperature</p></stm:description>
</stm:unit>
<!-- fundamental non-SI units -->
<stm:unit id="inch" name="inch" parentSI="meter"
abbreviation="in"
multiplierToSI="0.0254" >
<stm:description>An imperial measure of length</stm:description>
</stm:unit>
<!-- derived non-SI units -->
<stm:unit id="l" name="litre" unitType="volume"
parentSI="meterCubed"
abbreviation="l"
multiplierToSI="0.001">
<stm:description>Nearly 1 dm**3 This is not quite exact</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="fahr" name="fahrenheit" parentSI="k"
abbreviation="F"
multiplierToSI="0.55555555555555555"
constantToSI="-17.777777777777777777">
<stm:description>An obsolescent unit of temperature still used in popular
meteorology</stm:description>
</stm:unit>
</stm:unitList>
</pre></div>
<div class="example"><pre><stm:unitList
xmlns:stm="http://www.xml-cml.org/schema/stmml"
dictRef="unit" href="units.xml" />
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="unitType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="unit" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="tit_id_conv_dictGroup"/>
<xsd:attribute name="href" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Maps a <a href="st.dictRefType">dictRef</a>
prefix to the location of a dictionary.</div>
<div class="description">This requires the prefix and the physical URI
address to be contained within the same file. We can anticipate that
better mechanisms will arise - perhaps through XMLCatalogs.
At least it works at present.</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="unitType" id="el.unitType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An element containing the description of a scientific unit</div>
<div class="description"><p>Mandatory for SI Units,
optional for nonSI units since they should be able to obtain this
from their parent. For complex derived units without parents it may be
useful.</p>
<p>Used within a unitList</p>
<p>Distinguish carefully from <a href="st.unitsType">unitsType</a>
which is primarily used for attributes describing the units that elements
carry</p></div>
<div class="example">
<pre><stm:unitList xmlns:stm="http://www.xml-cml.org/schema/stmml">
<!-- ======================================================================= -->
<!-- ========================= fundamental types =========================== -->
<!-- ======================================================================= -->
<stm:unitType id="length" name="length">
<stm:dimension name="length"/>
</stm:unitType>
<stm:unitType id="time" name="time">
<stm:dimension name="time"/>
</stm:unitType>
<!-- ... -->
<stm:unitType id="dimensionless" name="dimensionless">
<stm:dimension name="dimensionless"/>
</stm:unitType>
<!-- ======================================================================= -->
<!-- ========================== derived types ============================== -->
<!-- ======================================================================= -->
<stm:unitType id="acceleration" name="acceleration">
<stm:dimension name="length"/>
<stm:dimension name="time" power="-2"/>
</stm:unitType>
<!-- ... -->
<!-- ======================================================================= -->
<!-- ====================== fundamental SI units =========================== -->
<!-- ======================================================================= -->
<stm:unit id="second" name="second" unitType="time">
<stm:description>The SI unit of time</stm:description>
</stm:unit>
<stm:unit id="meter" name="meter" unitType="length"
abbreviation="m">
<stm:description>The SI unit of length</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="kg" name="nameless" unitType="dimensionless"
abbreviation="nodim">
<stm:description>A fictitious parent for dimensionless units</stm:description>
</stm:unit>
<!-- ======================================================================= -->
<!-- ===================== derived SI units ================================ -->
<!-- ======================================================================= -->
<stm:unit id="newton" name="newton" unitType="force">
<stm:description>The SI unit of force</stm:description>
</stm:unit>
<!-- ... -->
<!-- multiples of fundamental SI units -->
<stm:unit id="g" name="gram" unitType="mass"
parentSI="kg"
multiplierToSI="0.001"
abbreviation="g">
<stm:description>0.001 kg. </stm:description>
</stm:unit>
<stm:unit id="celsius" name="Celsius" parentSI="k"
multiplierToSI="1"
constantToSI="273.18">
<stm:description><p>A common unit of temperature</p></stm:description>
</stm:unit>
<!-- fundamental non-SI units -->
<stm:unit id="inch" name="inch" parentSI="meter"
abbreviation="in"
multiplierToSI="0.0254" >
<stm:description>An imperial measure of length</stm:description>
</stm:unit>
<!-- derived non-SI units -->
<stm:unit id="l" name="litre" unitType="volume"
parentSI="meterCubed"
abbreviation="l"
multiplierToSI="0.001">
<stm:description>Nearly 1 dm**3 This is not quite exact</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="fahr" name="fahrenheit" parentSI="k"
abbreviation="F"
multiplierToSI="0.55555555555555555"
constantToSI="-17.777777777777777777">
<stm:description>An obsolescent unit of temperature still used in popular
meteorology</stm:description>
</stm:unit>
</stm:unitList>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="dimension" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="idType" use="required">
</xsd:attribute>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="unit" id="el.unit">
<xsd:annotation>
<xsd:documentation>
<div class="summary">A scientific unit</div>
<div class="description"><p>A scientific unit. Units are of the following types:</p>
<ul>
<li>SI Units. These may be one of the seven fundamental types
(e.g. meter) or may be derived (e.g. joule). An SI unit is
identifiable because it has no parentSI attribute and will have
a unitType attribute.</li>
<li>nonSI Units. These will normally have a parent SI unit
(e.g. calorie has joule as an SI parent). </li>
<li/>
</ul>
<p>Example:</p>
<pre>
<unit id="units:fahr" name="fahrenheit" parentSI="units:K"
multiplierToSI="0.55555555555555555"
constantToSI="-17.777777777777777777">
<description>An obsolescent unit of temperature still used in popular
meteorology</description>
</unit>
</pre>
</div>
</xsd:documentation>
<xsd:appinfo>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="description"/>
<xsd:element ref="annotation"/>
</xsd:choice>
<xsd:attribute name="id" type="xsd:string" use="required">
</xsd:attribute>
<xsd:attribute name="abbreviation" type="xsd:string">
</xsd:attribute>
<xsd:attribute name="name" type="xsd:string">
</xsd:attribute>
<xsd:attribute name="parentSI" type="xsd:string">
<xsd:annotation>
<xsd:documentation><div class="summary">
A reference to the parent SI unit (forbidden for SI Units themselves).
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="unitType" type="xsd:string">
<xsd:annotation>
<xsd:documentation><div class="summary">
A reference to the unitType (required for SI Units).
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="multiplierToSI" type="xsd:decimal" default="1">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>The factor by which the non-SI unit should be multiplied to
convert a quantity to its representation in SI Units.
This is applied <b>before</b> <tt>constantToSI</tt>.
Mandatory for nonSI units; forbidden for SI units</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="constantToSI" type="xsd:decimal" default="0">
<xsd:annotation>
<xsd:documentation>
<div class="summary"><p>The amount to add to a quantity in non-SI units to
convert its representation to SI Units.
This is applied <b>after</b> <tt>multiplierToSI</tt>.
Optional for nonSI units; forbidden for SI units.
</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:simpleType name="unitsType" id="st.unitsType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Scientific units</div>
<div class="description"><p>Scientific units. These will be linked to dictionaries of units with
conversion information, using namespaced references (e.g. <tt>si:m</tt>)
</p>
<p>Distinguish carefully from <a href="st.unitType">unitType</a>
which is an element describing a type of a unit in a <a href="el.unitList">unitList</a>
</p></div>
<div class="example"><pre><stm:unitList xmlns:stm="http://www.xml-cml.org/schema/stmml">
<!-- ======================================================================= -->
<!-- ========================= fundamental types =========================== -->
<!-- ======================================================================= -->
<stm:unitType id="length" name="length">
<stm:dimension name="length"/>
</stm:unitType>
<stm:unitType id="time" name="time">
<stm:dimension name="time"/>
</stm:unitType>
<!-- ... -->
<stm:unitType id="dimensionless" name="dimensionless">
<stm:dimension name="dimensionless"/>
</stm:unitType>
<!-- ======================================================================= -->
<!-- ========================== derived types ============================== -->
<!-- ======================================================================= -->
<stm:unitType id="acceleration" name="acceleration">
<stm:dimension name="length"/>
<stm:dimension name="time" power="-2"/>
</stm:unitType>
<!-- ... -->
<!-- ======================================================================= -->
<!-- ====================== fundamental SI units =========================== -->
<!-- ======================================================================= -->
<stm:unit id="second" name="second" unitType="time">
<stm:description>The SI unit of time</stm:description>
</stm:unit>
<stm:unit id="meter" name="meter" unitType="length"
abbreviation="m">
<stm:description>The SI unit of length</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="kg" name="nameless" unitType="dimensionless"
abbreviation="nodim">
<stm:description>A fictitious parent for dimensionless units</stm:description>
</stm:unit>
<!-- ======================================================================= -->
<!-- ===================== derived SI units ================================ -->
<!-- ======================================================================= -->
<stm:unit id="newton" name="newton" unitType="force">
<stm:description>The SI unit of force</stm:description>
</stm:unit>
<!-- ... -->
<!-- multiples of fundamental SI units -->
<stm:unit id="g" name="gram" unitType="mass"
parentSI="kg"
multiplierToSI="0.001"
abbreviation="g">
<stm:description>0.001 kg. </stm:description>
</stm:unit>
<stm:unit id="celsius" name="Celsius" parentSI="k"
multiplierToSI="1"
constantToSI="273.18">
<stm:description><p>A common unit of temperature</p></stm:description>
</stm:unit>
<!-- fundamental non-SI units -->
<stm:unit id="inch" name="inch" parentSI="meter"
abbreviation="in"
multiplierToSI="0.0254" >
<stm:description>An imperial measure of length</stm:description>
</stm:unit>
<!-- derived non-SI units -->
<stm:unit id="l" name="litre" unitType="volume"
parentSI="meterCubed"
abbreviation="l"
multiplierToSI="0.001">
<stm:description>Nearly 1 dm**3 This is not quite exact</stm:description>
</stm:unit>
<!-- ... -->
<stm:unit id="fahr" name="fahrenheit" parentSI="k"
abbreviation="F"
multiplierToSI="0.55555555555555555"
constantToSI="-17.777777777777777777">
<stm:description>An obsolescent unit of temperature still used in popular
meteorology</stm:description>
</stm:unit>
</stm:unitList>
</pre></div>
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:annotation>
<xsd:documentation>
<div class="heading">Groups (for schema maintenance and re-use)</div>
</xsd:documentation>
</xsd:annotation>
<xsd:attributeGroup name="actionGroup" id="attGp.action">
<xsd:attribute name="start" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The start time</div>
<div class="description">
<p>The start time in any allowable XSD representation of date, time or dateTime.
This will normally be a clock time or date.</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="startCondition" type="xsd:string"/>
<xsd:attribute name="duration" type="xsd:string">
</xsd:attribute>
<xsd:attribute name="end" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">The end time</div>
<div class="description">
<p>The start time in any allowable XSD representation of date, time or dateTime.
This will normally be a clock time or date.</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="endCondition" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>The end condition</p>
</div>
<div class="description">
<p>At present a human-readable string describing some condition when the
ac tion should end. As XML develops it may be possible to add machine-processable
semantics in this field.</p>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="units" type="unitsType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Units for the time attributes</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="count" type="countType">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Number of times the action should be repeated</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:group name="dataGroup" id="gp.dataGroup">
<xsd:annotation>
<xsd:documentation>
<div class="summary">
<p>A grouping of <tt>list</tt> and <tt>scalar</tt> elements for use by
other schemas. Experimental.</p>
</div>
<div class="description">
<p>This is to allow non-STM schemas to include a generic "data" component
in their elements. It is messy and probably should not survive. Better
extensibility mechanisms should be found.</p>
<p>Use only within Schemas</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element ref="list"/>
<xsd:element ref="scalar"/>
</xsd:choice>
</xsd:group>
<xsd:attributeGroup name="sourceGroup" id="attGp.source">
<xsd:attribute id="att.source" name="source" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An attribute linking to the source of the information</div>
<div class="description">
<p>A simple way of adding metadata to a piece of information.
Likely to be fragile since the URI may disappear.</p>
</div>
<div class="example">
<pre>
<list>
<definition source="foo.html#a3">An animal with four legs</definition>
<definition source="http://www.foo.com/index.html">
An animal with six legs</definition>
</list>
</pre>
</div>
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:attributeGroup name="tit_id_convGroup" id="attGp.tit_id_convGroup">
<xsd:annotation>
<xsd:documentation>
<div class="summary">An group of attribute applicable to most STMML elements</div>
<div class="description"><p>A group of attribute applicable to most STMML elements. It is
recommended that IDs are used widely. Titles have no semantics but
are useful for humans (e.g. a bond angle could be labelled "ortho"
or "gamma". Conventions are inherited by subelements; the default is the
current schema.</p>
</div>
</xsd:documentation>
</xsd:annotation>
<xsd:attributeGroup ref="idGroup"/>
<xsd:attributeGroup ref="titleGroup"/>
<xsd:attributeGroup ref="convGroup"/>
</xsd:attributeGroup>
<xsd:attributeGroup name="tit_id_conv_dictGroup" id="attGp.tit_id_conv_dictGroup">
<xsd:annotation>
<xsd:documentation>
<div class="summary">Addition of the <tt>dictRef</tt> attribute to the <tt>tit_id_conv</tt> group.</div>
</xsd:documentation>
</xsd:annotation>
<xsd:attributeGroup ref="tit_id_convGroup"/>
<xsd:attributeGroup ref="dictRefGroup"/>
</xsd:attributeGroup>
</xsd:schema>
Submitted for publication, February 7, 2002.