<h:div class="summary">A container for a list of atoms.</h:div><h:div class="description">A child of _molecule_ and contains _atom_ information. There are two strategies:<h:ul><h:li>Create individual _atom_ elements under _atomArray_ (in any order). This gives the greatest flexibility but is the most verbose.</h:li><h:li>Create<h:tt>*Array</h:tt>attributes (e.g. of _elementTypeArrayType_ under _atomArray_. This requires all arrays to be of identical lengths with explicit values for all atoms in every array. This is NOT suitable for complexType atom children such as _atomParity_. It also cannot be checked as easily by schema- and schematron validation. The _atomIDArray_ attribute is mandatory. It is allowed (though not yet recommended) to add _*Array_ children such as _floatArray_</h:li></h:ul>The attributes are directly related to the scalar attributes under _atom_ which should be consulted for more info.</h:div><h:div class="example" href="atomArray1.xml"><h:p>Example - these are exactly equivalent representations</h:p></h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">Array of object counts.</h:div><h:div class="description">No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">An array of formalCharges.</h:div><h:div class="description">Used in CML2 Array mode. NOT the calculated charge or oxidation state. No formal defaults, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">Normally used in CML2 array mode. The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Array of occupancies.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">array of x2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<h:div class="summary">Array of fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<h:div class="summary">array of y2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<h:div class="summary">Array of fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<h:div class="summary">Array of fractional z coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
Source
<xsd:element name="atomArray" id="el.atomArray"><xsd:annotation><xsd:documentation><h:div class="summary">A container for a list of atoms.</h:div><h:div class="description">A child of _molecule_ and contains _atom_ information. There are two strategies:<h:ul><h:li>Create individual _atom_ elements under _atomArray_ (in any order). This gives the greatest flexibility but is the most verbose.</h:li><h:li>Create<h:tt>*Array</h:tt>attributes (e.g. of _elementTypeArrayType_ under _atomArray_. This requires all arrays to be of identical lengths with explicit values for all atoms in every array. This is NOT suitable for complexType atom children such as _atomParity_. It also cannot be checked as easily by schema- and schematron validation. The _atomIDArray_ attribute is mandatory. It is allowed (though not yet recommended) to add _*Array_ children such as _floatArray_</h:li></h:ul>The attributes are directly related to the scalar attributes under _atom_ which should be consulted for more info.</h:div><h:div class="example" href="atomArray1.xml"><h:p>Example - these are exactly equivalent representations</h:p></h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="atom" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="array" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="elementTypeArray"/><xsd:attributeGroup ref="countArray"/><xsd:attributeGroup ref="formalChargeArray"/><xsd:attributeGroup ref="hydrogenCountArray"/><xsd:attributeGroup ref="occupancyArray"/><xsd:attributeGroup ref="x2Array"/><xsd:attributeGroup ref="y2Array"/><xsd:attributeGroup ref="x3Array"/><xsd:attributeGroup ref="y3Array"/><xsd:attributeGroup ref="z3Array"/><xsd:attributeGroup ref="xFractArray"/><xsd:attributeGroup ref="yFractArray"/><xsd:attributeGroup ref="zFractArray"/><xsd:attributeGroup ref="atomIDArray"/></xsd:complexType></xsd:element>
Element atom
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An atom.</h:div><h:div documentation="general">Atoms can only be chosen from the periodic table and superatoms such as "Phe" or "Tyr" are not allowed. The elementType of an atom is identified by that attribute. There are two additional elementTypes, "Du" (for an object which does not have an identifiable nucleus but is useful in calculations and definitions (such as a centroid); and "R" which describes a generic fragment. Although atoms have an elementType, they do not, by default, support arbitrary atomTypes for which the <atomType> element should be used.</h:div><h:div class="example" href="atom1.xml"/><h:div class="curation">2006-01-12: PMR. Added vector3 child to support
accelerations, velocities, dipole, etc.</h:div><h:div class="curation">2006-06-01: PMR. Added documentation.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<h:div class="summary">Number of hydrogens.</h:div><h:div class="description">The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Reference to a description of the isotopic composition of an atom.</h:div><h:div class="description">Used when more than one atom shares the same isotopic composition (e.g. when H/D have been scrambled over some or all of the atoms in a molecule..</h:div><h:div class="example" href="isotope1.xml"/>
<h:div class="summary">The integer number for an isotope.</h:div><h:div class="description">The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef).</h:div>
<h:div class="summary">Reference to a fuller description of the isotope.</h:div><h:div class="general">The description may be found in an external collection (e.g. IUPAC) or within the current document.</h:div><h:div class="example" href="isotope2.xml"/>
<h:div class="summary">Occupancy for an atom.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms.</h:div>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the pointGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 60 (for icosahedral). It represents the number of symmetry operations
(without any translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a pointGroupMultiplicity of 2.
The pointGroupMultiplicity can be deduced from a knowledge of the
coordinates and the pointGroup operators and so is formally redundant but this is a
useful convenience operator.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the spaceGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 192. It represents the number of symmetry operations
(without cell translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a spaceGroupMultiplicity of 2.
The spaceGroupMultiplicity can be deduced from a knowledge of the
coordinates and the spaceGroup operators and so is formally redundant but this is a
useful convenience operator. Some crystallographic experiments report this attribute
as, for example, the IUCr CIF item 'atom_site_symmetry_multiplicity'.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
<h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div>
<h:div class="summary">x2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div>
<h:div class="summary">Fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<h:div class="summary">y2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2
dimensions. Unrelated to the 3-D coordinates for the object. The
orientation of the axes matters as it can affect the chirality of
object.</h:div>
<h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
<h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
Source
<xsd:element name="atom" id="el.atom"><xsd:annotation><xsd:documentation><h:div class="summary">An atom.</h:div><h:div documentation="general">Atoms can only be chosen from the periodic table and superatoms such as "Phe" or "Tyr" are not allowed. The elementType of an atom is identified by that attribute. There are two additional elementTypes, "Du" (for an object which does not have an identifiable nucleus but is useful in calculations and definitions (such as a centroid); and "R" which describes a generic fragment. Although atoms have an elementType, they do not, by default, support arbitrary atomTypes for which the <atomType> element should be used.</h:div><h:div class="example" href="atom1.xml"/><h:div class="curation">2006-01-12: PMR. Added vector3 child to support
accelerations, velocities, dipole, etc.</h:div><h:div class="curation">2006-06-01: PMR. Added documentation.</h:div></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:complexType><xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="general"><h:p>The main content model of the atom.</h:p><h:ul><h:li><h:b>name</h:b>can be used for atom labels, etc. More than one name can be used if required.</h:li><h:li><h:b>scalar</h:b>contains any scalar properties of the atom (examples are chemical shift, B-value, etc.) linked through<h:tt>dictRef</h:tt>(CmlDictRefType).</h:li><h:li><h:b>array</h:b>contains any properties of the atom describable by a homogeneous array linked through<h:tt>dictRef</h:tt>(CmlDictRefType).</h:li><h:li><h:b>matrix</h:b>contains any properties of the atom describable by a homogeneous matrix linked through<h:tt>dictRef</h:tt>(CmlDictRefType). An example is the polarizability tensor</h:li><h:li><h:b>atomParity</h:b>(CmlAtomParityElement) the required way of defining atom-based chirality</h:li><h:li><h:b>electron</h:b>a away of associating electron(s) with the atom</h:li></h:ul></h:div></xsd:documentation></xsd:annotation><xsd:element ref="name"/><xsd:element ref="label"/><xsd:element ref="atomType"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="scalar"/><xsd:element ref="atomParity"/><xsd:element ref="electron"/><xsd:element ref="particle"/><xsd:element ref="vector3"/></xsd:choice></xsd:choice><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="count"><xsd:annotation><xsd:documentation><h:div class="specific">Most useful in _formula_ but possibly useful in _atomArray_ where coordinates and connectivity is not defined. No formal default, but assumed to be 1.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="elementType"/><xsd:attributeGroup ref="formalCharge"/><xsd:attributeGroup ref="hydrogenCount"/><xsd:attributeGroup ref="isotope"/><xsd:attributeGroup ref="isotopeNumber"/><xsd:attributeGroup ref="isotopeRef"/><xsd:attributeGroup ref="isotopeListRef"/><xsd:attributeGroup ref="occupancy"/><xsd:attributeGroup ref="spinMultiplicity"/><xsd:attributeGroup ref="x2"/><xsd:attributeGroup ref="y2"/><xsd:attributeGroup ref="x3"/><xsd:attributeGroup ref="y3"/><xsd:attributeGroup ref="z3"/><xsd:attributeGroup ref="xFract"/><xsd:attributeGroup ref="yFract"/><xsd:attributeGroup ref="zFract"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">This can be used to describe the purpose of atoms whose _elementType_s are __dummy__ or __locant__. Vocabulary not controlled.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="spaceGroupMultiplicity"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-27: Added PMR</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="pointGroupMultiplicity"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-27: Added PMR</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element name
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A string identifying a object.</h:div><h:div class="description"><h:tt>name</h:tt>is used for chemical names (formal and trivial) for molecules and also for identifiers such as CAS registry and RTECS. It can also be used for labelling atoms. It should be used in preference to the<h:tt>title</h:tt>attribute because it is repeatable and can be linked to a dictionary.<h:p>Constraining patterns can be described in the dictionary and used to validate<h:tt>name</h:tt>s.</h:p></h:div><h:div class="example" href="name1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
Source
<xsd:element name="name" id="el.name"><xsd:annotation><xsd:documentation><h:div class="summary">A string identifying a object.</h:div><h:div class="description"><h:tt>name</h:tt>is used for chemical names (formal and trivial) for molecules and also for identifiers such as CAS registry and RTECS. It can also be used for labelling atoms. It should be used in preference to the<h:tt>title</h:tt>attribute because it is repeatable and can be linked to a dictionary.<h:p>Constraining patterns can be described in the dictionary and used to validate<h:tt>name</h:tt>s.</h:p></h:div><h:div class="example" href="name1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element label
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A text string qualifying an object.</h:div><h:div class="description">A label can be used to identify or distinguish elements, add keywords or classifications and similar processes. It is usually interpretable by domain-aware humans (e.g. C3'-endo, but not a34561). It is usually either built in a semantically rich fashion (e.g. C2'-alpha-H) or belongs to a controlled vocabulary. It is possibly accessed by software in a domain-specific manner. It differs from<h:tt>description</h:tt>which is free text. The distinction between titles, names and labels is fuzzy, but we think this is worth making. Labels may be necesssary to identify objects within programs, while names are more likely to be reserved for database searches. Titles are likely to be freer text and not recommended for precise object retrieval.</h:div><h:div class="note">Labels should not contain whitespace. Punctuation marks are often necessary, but should not be gratuitously used. Punctuation clashing with XML character entities should be avoided; if this is not possible it should be escaped.</h:div><h:div class="example" href="label1.xml"><h:em>From IUPAC Dictionary of Medicinal Chemistry</h:em></h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
Source
<xsd:element name="label" id="el.label"><xsd:annotation><xsd:documentation><h:div class="summary">A text string qualifying an object.</h:div><h:div class="description">A label can be used to identify or distinguish elements, add keywords or classifications and similar processes. It is usually interpretable by domain-aware humans (e.g. C3'-endo, but not a34561). It is usually either built in a semantically rich fashion (e.g. C2'-alpha-H) or belongs to a controlled vocabulary. It is possibly accessed by software in a domain-specific manner. It differs from<h:tt>description</h:tt>which is free text. The distinction between titles, names and labels is fuzzy, but we think this is worth making. Labels may be necesssary to identify objects within programs, while names are more likely to be reserved for database searches. Titles are likely to be freer text and not recommended for precise object retrieval.</h:div><h:div class="note">Labels should not contain whitespace. Punctuation marks are often necessary, but should not be gratuitously used. Punctuation clashing with XML character entities should be avoided; if this is not possible it should be escaped.</h:div><h:div class="example" href="label1.xml"><h:em>From IUPAC Dictionary of Medicinal Chemistry</h:em></h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="value"/><xsd:attributeGroup ref="objectClass"/></xsd:complexType></xsd:element>
Element atomType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An atomType.</h:div><h:div class="description"><h:p>atomTypes are used in a wide variety of ways in computational chemistry.
They are normally labels added to existing atoms (or dummy atoms)
in the molecule and have a number of defined properties.
These properties are usually in addition to those deducible from the
elementType of the atom. AtomTypes usually depend on the chemical or
geometrical environment of the atom and are frequently assigned by
algorithms with chemical perception. However they are often frequently
set or "tweaked" by humans initiating a program run.</h:p><h:p>AtomTypes on an atom have no formal relation to its<h:tt>elementType</h:tt>,
which only describe the number of protons in the nucleus. It is not unknown
(though potentially misleading) to use an "incompatible" atomType to
alter the computational properties of an atom (e.g. pretend this K+
is a Ca++ to increase its effective charge).<h:tt>atomTypes</h:tt>will also be required to describe pseudoAtoms such as "halogen"
(generic) or "methyl group" (unified atom). Atoms in computations
can therefore have an<h:tt>atomType</h:tt>child with a "ref"
attribute.</h:p><h:p>An atomType contains numeric or other quantities associated with
it (charges, masses, use in force-fields, etc.) and also description
of any perception algorithms (chemical and/or geometrical) which could
be used to compute or constrain it. This is still experimental.</h:p><h:p>atomTypes are referred to by their mandatory<h:tt>name</h:tt>attribute. An atom refers to one or more atomTypes through
atomType/@ref children</h:p></h:div><h:div class="example" href="atomType1.xml"/><h:div class="note">examples not yet teste.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="atomType" id="el.atomType"><xsd:annotation><xsd:documentation><h:div class="summary">An atomType.</h:div><h:div class="description"><h:p>atomTypes are used in a wide variety of ways in computational chemistry.
They are normally labels added to existing atoms (or dummy atoms)
in the molecule and have a number of defined properties.
These properties are usually in addition to those deducible from the
elementType of the atom. AtomTypes usually depend on the chemical or
geometrical environment of the atom and are frequently assigned by
algorithms with chemical perception. However they are often frequently
set or "tweaked" by humans initiating a program run.</h:p><h:p>AtomTypes on an atom have no formal relation to its<h:tt>elementType</h:tt>,
which only describe the number of protons in the nucleus. It is not unknown
(though potentially misleading) to use an "incompatible" atomType to
alter the computational properties of an atom (e.g. pretend this K+
is a Ca++ to increase its effective charge).<h:tt>atomTypes</h:tt>will also be required to describe pseudoAtoms such as "halogen"
(generic) or "methyl group" (unified atom). Atoms in computations
can therefore have an<h:tt>atomType</h:tt>child with a "ref"
attribute.</h:p><h:p>An atomType contains numeric or other quantities associated with
it (charges, masses, use in force-fields, etc.) and also description
of any perception algorithms (chemical and/or geometrical) which could
be used to compute or constrain it. This is still experimental.</h:p><h:p>atomTypes are referred to by their mandatory<h:tt>name</h:tt>attribute. An atom refers to one or more atomTypes through
atomType/@ref children</h:p></h:div><h:div class="example" href="atomType1.xml"/><h:div class="note">examples not yet teste.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="molecule"/><xsd:element ref="atom"/><xsd:element ref="label"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="property"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="name"><xsd:annotation><xsd:documentation><h:div class="specific">The name will usually be namespaced as 'gulp:si', 'tripos:c.3', etc. It must occur except for atomType/@re.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="ref"/><!-- what do we need this for? --><xsd:attributeGroup ref="atomRef"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element molecule
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for atoms, bonds and submolecules.</h:div><h:div class="description"><h:p><h:tt>molecule</h:tt>is a container for atoms, bonds and submolecules along
with properties such as crystal and non-builtin properties. It should either
contain<h:tt>molecule</h:tt>or *Array for atoms and bonds. A molecule
can be empty (e.g. we just know its name, id, etc.)</h:p><h:p>"Molecule" need not represent a chemically meaningful molecule. It
can contain atoms with bonds (as in the solid-sate) and it could
simply carry a name (e.g. "taxol") without formal representation
of the structure. It can contain "sub molecules", which are often
discrete subcomponents (e.g. guest-host).</h:p><h:p>Molecule can contain a <list> element to contain data
related to the molecule.
Within this can be string/float/integer and other nested lists</h:p></h:div><h:div><h:p>Normally molecule will not contain fragment or fragmentList</h:p></h:div><h:div class="example" href="molecule1.xml"/><h:div class="curation">Revised content model to allow any order of lengths, angles, torsions 2003-01-01..</h:div><h:div class="curation">Added role attribute 2003-03-19..</h:div><h:div class="curation">2006-05-21. PMR changed content model to (A|B|C...)*</h:div><h:div class="curation">2006-11-24. PMR removed @tail, @head, @countExpression, @repeat</h:div>
<h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<h:div class="summary">Simple chemical formula.</h:div><h:div class="general">This attribute should only be used for simple formulae (i.e. without brackets or other nesting for which a _formula_ child element should be used. The attribute might be used as a check on the child elements or for ease of representation. Essentially the same as _concise_ attribute on _formula.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Allows a referring element to generate a unique id.</h:div><h:div class="description">idgen can hold a unique identifier which is copied into the id
attribute of the referenced element. This avoids multiple copies of the referenced
object with duplicate ids. EXPERIMENTAL</h:div><h:div class="curation">2006-05-22: PMR added.</h:div>
<h:div class="summary">Keyword signifying how object is to be processed.</h:div><h:div class="description">Semantics depend on the parent element</h:div><h:div class="curation">2006-05-20: PMR added</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div>
<h:div class="summary">Is the molecule oriented to the symmetry</h:div><h:div class="description">No formal default, but a molecule is assumed to be oriented according to any _symmetry_ children. This is required for crystallographic data, but some systems for isolated molecules allow specification of arbitrary Cartesian or internal coordinates, which must be fitted or refined to a prescribed symmetry. In this case the attribute value is false.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="molecule" id="el.molecule"><xsd:annotation><xsd:documentation><h:div class="summary">A container for atoms, bonds and submolecules.</h:div><h:div class="description"><h:p><h:tt>molecule</h:tt>is a container for atoms, bonds and submolecules along
with properties such as crystal and non-builtin properties. It should either
contain<h:tt>molecule</h:tt>or *Array for atoms and bonds. A molecule
can be empty (e.g. we just know its name, id, etc.)</h:p><h:p>"Molecule" need not represent a chemically meaningful molecule. It
can contain atoms with bonds (as in the solid-sate) and it could
simply carry a name (e.g. "taxol") without formal representation
of the structure. It can contain "sub molecules", which are often
discrete subcomponents (e.g. guest-host).</h:p><h:p>Molecule can contain a <list> element to contain data
related to the molecule.
Within this can be string/float/integer and other nested lists</h:p></h:div><h:div><h:p>Normally molecule will not contain fragment or fragmentList</h:p></h:div><h:div class="example" href="molecule1.xml"/><h:div class="curation">Revised content model to allow any order of lengths, angles, torsions 2003-01-01..</h:div><h:div class="curation">Added role attribute 2003-03-19..</h:div><h:div class="curation">2006-05-21. PMR changed content model to (A|B|C...)*</h:div><h:div class="curation">2006-11-24. PMR removed @tail, @head, @countExpression, @repeat</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div class="summary">The float|integer|string children are for compatibility with CML-1 and are deprecated. scalar|array|matrix should be used instead.</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="angle"/><xsd:element ref="arg"/><xsd:element ref="array"/><xsd:element ref="atomArray"/><xsd:element ref="bondArray"/><xsd:element ref="crystal"/><xsd:element ref="electron"/><xsd:element ref="formula"/><xsd:element ref="identifier"/><xsd:element ref="join"/><xsd:element ref="label"/><xsd:element ref="length"/><xsd:element ref="list"/><xsd:element ref="matrix"/><xsd:element ref="metadataList"/><xsd:element ref="molecule"/><xsd:element ref="name"/><xsd:element ref="propertyList"/><xsd:element ref="scalar"/><xsd:element ref="symmetry"/><xsd:element ref="torsion"/><xsd:element ref="zMatrix"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="idgen"/><xsd:attributeGroup ref="process"/><xsd:attributeGroup ref="formula"/><xsd:attributeGroup ref="count"/><xsd:attributeGroup ref="chirality"/><xsd:attributeGroup ref="formalCharge"/><xsd:attributeGroup ref="spinMultiplicity"/><xsd:attributeGroup ref="symmetryOriented"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>No formal semantics (yet). The role describes the purpose of the molecule element at this stage in the information. Examples can be "conformation", "dynamicsStep", "vibration", "valenceBondIsomer", etc. This attribute may be used by applications to determine how to present a set of molecule elements.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element angle
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An angle between three atoms.</h:div><h:div class="description"><h:p>It can be used for:</h:p><h:ul><h:li>Recording experimentally determined bond angles (e.g. in
a crystallographic paper).</h:li><h:li>Providing the angle component for internal coordinates (e.g.
z-matrix).</h:li></h:ul></h:div><h:div class="example" href="angle1.xml"/>
<h:div class="summary">A list of three references to atoms.</h:div><h:div class="description">Typically used for defining angles,
but could also be used to define a three-centre bond.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Restricts units to radians or degrees.</h:div><h:div class="description"/>
Source
<xsd:element name="angle" id="el.angle"><xsd:annotation><xsd:documentation><h:div class="summary">An angle between three atoms.</h:div><h:div class="description"><h:p>It can be used for:</h:p><h:ul><h:li>Recording experimentally determined bond angles (e.g. in
a crystallographic paper).</h:li><h:li>Providing the angle component for internal coordinates (e.g.
z-matrix).</h:li></h:ul></h:div><h:div class="example" href="angle1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="nonNegativeAngleType"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="atomRefs3"/><xsd:attributeGroup ref="angleUnits"/><xsd:attributeGroup ref="errorValue"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="min"/><xsd:attributeGroup ref="max"/><xsd:attributeGroup ref="ref"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element arg
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An argument for a function.</h:div><h:div class="description">Arguments can be typed and have explicit
or free values. They can also carry out substitutions in the parent element
and its children (substitute, still experiemental) and delete itself after
this.</h:div><h:div class="curation">2006-02-14: PMR. Added atomType as child</h:div><h:div class="curation">2006-05-21: PMR. Added substitute and delete
attributes</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A flag indicated that the element can detach/delete itself.</h:div><h:div class="description">An element containg this attribute may only have a transient existence
(e.g. a template to create other elements) and this attribute shows that
the element can be deleted at the appropriate stage. The time at which this
is called is application dependent. At present the presence of the attribute
is sufficient to trigger this; later a controlled vocabulary will be developed.</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A flag on 'arg' to indicate that the value can be calculated.</h:div><h:div class="description">This is still experimental. if eval="_ijk_+3" and
the value of the ijk was 2, this would change the value of the arg to 5.
Only + and - are currently allowed</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">parameter name passed to an element</h:div><h:div class="description">This is still experimental.</h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
<h:div class="summary">raplaces attribute on parent</h:div><h:div class="description">This is still experimental. Creates, overwriting
if necessary, an attribute on parent. Example:<h:pre><foo>
<arg parentAttribute="bar">zubbo</arg></h:pre>will create an attribute bar="zubbo" on <foo></h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A flag on 'arg' to indicate that the value can be substituted.</h:div><h:div class="description">This is still experimental. The value may be an
XPath expression, at present
all attributes (".//@*") are processed. If an attribute contains _ijk_ where the
name of the arg is 'ijk' this string is replaced by the value of ijk,
e.g. if arg with name ijk has a value of 2 then 'm_ijk__z3' becomes
'm2_z3'. substitute="." replaces this element by its value</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="arg" id="el.arg"><xsd:annotation><xsd:documentation><h:div class="summary">An argument for a function.</h:div><h:div class="description">Arguments can be typed and have explicit
or free values. They can also carry out substitutions in the parent element
and its children (substitute, still experiemental) and delete itself after
this.</h:div><h:div class="curation">2006-02-14: PMR. Added atomType as child</h:div><h:div class="curation">2006-05-21: PMR. Added substitute and delete
attributes</h:div><h:div class="example" href="potential1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="atom"/><xsd:element ref="atomType"/><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="expression"/><!-- Xerces doesn't let me do this
<xsd:any processContents="lax"/>
--></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="substitute"/><xsd:attributeGroup ref="parameterName"/><xsd:attributeGroup ref="parentAttribute"/><xsd:attributeGroup ref="delete"/><xsd:attributeGroup ref="eval"/></xsd:complexType></xsd:element>
Element scalar
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An element to hold scalar data.</h:div><h:div class="description"><h:tt>scalar</h:tt>holds scalar data under a single
generic container. The semantics are usually resolved by
linking to a dictionary.<h:b>scalar</h:b>defaults to a scalar string but
has attributes which affect the type.<h:p><h:tt>scalar</h:tt>does not necessarily reflect a physical object (for which<h:a href="el.object">object</h:a>should be used). It may reflect a property of an object
such as temperature, size, etc.</h:p><h:p>Note that normal Schema validation tools cannot validate the data type
of<h:b>scalar</h:b>(it is defined as<h:tt>string</h: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.</h:p></h:div><h:div class="example" href="scalar1.xml"/>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="scalar" id="el.scalar"><xsd:annotation><xsd:documentation><h:div class="summary">An element to hold scalar data.</h:div><h:div class="description"><h:tt>scalar</h:tt>holds scalar data under a single
generic container. The semantics are usually resolved by
linking to a dictionary.<h:b>scalar</h:b>defaults to a scalar string but
has attributes which affect the type.<h:p><h:tt>scalar</h:tt>does not necessarily reflect a physical object (for which<h:a href="el.object">object</h:a>should be used). It may reflect a property of an object
such as temperature, size, etc.</h:p><h:p>Note that normal Schema validation tools cannot validate the data type
of<h:b>scalar</h:b>(it is defined as<h:tt>string</h: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.</h:p></h:div><h:div class="example" href="scalar1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="errorValue"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="min"/><xsd:attributeGroup ref="max"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="constantToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="multiplierToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="unitType"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with multiplierToSI and/or constantToSI</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element array
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A homogenous 1 dimensional array of similar object.</h:div><h:div class="description">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. The default delimiter is whitespace. The _normalize-space()_ function of XSLT could be used to normalize all whitespace to single spaces and this should not affect the value of the array elements. To extract the elements __java.lang.StringTokenizer__ could be used. If the elements themselves contain whitespace then a different delimiter must be used and is identified through the<h:tt>delimiter</h: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<h:tt>size+1</h: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.<h:p>Note that normal Schema validation tools cannot validate the elements
of<h:b>array</h:b>(they are defined as<h:tt>string</h: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.</h:p><h:p>When the elements of the<h:tt>array</h:tt>are not simple scalars
(e.g.<h:a href="el.scalar">scalar</h:a>s with a value and an error, the<h:tt>scalar</h: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.</h:p></h:div><h:div class="example" href="array1.xml"><h:p>the<h:tt>size</h:tt>attribute is not mandatory but provides a useful validity
check):</h:p></h:div>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div>
<h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="array" id="el.array"><xsd:annotation><xsd:documentation><h:div class="summary">A homogenous 1 dimensional array of similar object.</h:div><h:div class="description">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. The default delimiter is whitespace. The _normalize-space()_ function of XSLT could be used to normalize all whitespace to single spaces and this should not affect the value of the array elements. To extract the elements __java.lang.StringTokenizer__ could be used. If the elements themselves contain whitespace then a different delimiter must be used and is identified through the<h:tt>delimiter</h: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<h:tt>size+1</h: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.<h:p>Note that normal Schema validation tools cannot validate the elements
of<h:b>array</h:b>(they are defined as<h:tt>string</h: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.</h:p><h:p>When the elements of the<h:tt>array</h:tt>are not simple scalars
(e.g.<h:a href="el.scalar">scalar</h:a>s with a value and an error, the<h:tt>scalar</h: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.</h:p></h:div><h:div class="example" href="array1.xml"><h:p>the<h:tt>size</h:tt>attribute is not mandatory but provides a useful validity
check):</h:p></h:div><!--
<h:div class="example" href="array2.xml">
<h:p>Note that the second array-element is the empty string ''.</h:p></h:div>
<h:div class="example" href="array3.xml"></h:div>
--></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="errorValueArray"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="minValueArray"/><xsd:attributeGroup ref="maxValueArray"/><xsd:attributeGroup ref="start"/><xsd:attributeGroup ref="end"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="delimiter"/><xsd:attributeGroup ref="size"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="constantToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="multiplierToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="unitType"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with multiplierToSI and/or constantToSI</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element matrix
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A rectangular matrix of any quantities.</h:div><h:div class="description"><h:p>By default<h:tt>matrix</h:tt>represents
a rectangular matrix of any quantities
representable as XSD or STMML dataTypes. It consists of<h:tt>rows*columns</h:tt>elements, where<h:tt>columns</h:tt>is the
fasting moving index. Assuming the elements are counted from 1 they are
ordered<h: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]</h:tt></h:p><h:p>By default whitespace is used to separate matrix elements; see<h:a href="el.array">array</h:a>for details. There are NO characters or markup
delimiting the end of rows; authors must be careful!. The<h:tt>columns</h:tt>and<h:tt>rows</h:tt>attributes have no default values; a row vector requires
a<h:tt>rows</h:tt>attribute of 1.</h:p><h:p><h:tt>matrix</h: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<h:tt>matrixType</h:tt>attribute allows software to
validate and process the type of matrix.</h:p></h:div><h:div class="example" href="matrix1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div>
<h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="matrix" id="el.matrix"><xsd:annotation><xsd:documentation><h:div class="summary">A rectangular matrix of any quantities.</h:div><h:div class="description"><h:p>By default<h:tt>matrix</h:tt>represents
a rectangular matrix of any quantities
representable as XSD or STMML dataTypes. It consists of<h:tt>rows*columns</h:tt>elements, where<h:tt>columns</h:tt>is the
fasting moving index. Assuming the elements are counted from 1 they are
ordered<h: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]</h:tt></h:p><h:p>By default whitespace is used to separate matrix elements; see<h:a href="el.array">array</h:a>for details. There are NO characters or markup
delimiting the end of rows; authors must be careful!. The<h:tt>columns</h:tt>and<h:tt>rows</h:tt>attributes have no default values; a row vector requires
a<h:tt>rows</h:tt>attribute of 1.</h:p><h:p><h:tt>matrix</h: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<h:tt>matrixType</h:tt>attribute allows software to
validate and process the type of matrix.</h:p></h:div><h:div class="example" href="matrix1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="delimiter"/><xsd:attributeGroup ref="rows"/><xsd:attributeGroup ref="columns"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="matrixType"/><xsd:attributeGroup ref="errorValueArray"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="minValueArray"/><xsd:attributeGroup ref="maxValueArray"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element expression
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An expression that can be evaluated.</h:div><h:div class="description">Experimental. This is essentially a mathematical function, expressed currently in reverse Polish notation but we expect to move to MathML.</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="expression" id="el.expression"><xsd:annotation><xsd:documentation><h:div class="summary">An expression that can be evaluated.</h:div><h:div class="description">Experimental. This is essentially a mathematical function, expressed currently in reverse Polish notation but we expect to move to MathML.</h:div><h:div class="example" href="potential1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="parameter"/><xsd:element ref="operator"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="dataType"/></xsd:complexType></xsd:element>
Element parameter
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A parameter describing the computation.</h:div><h:div class="description"><h:p>A parameter is a broad concept and can describe numeric quantities, objects,
keywords, etc. The distinction between keywords and parameters is often fuzzy.
("MINIM" might mean "minimize", while "MINIM=3" might require three iterations
to be run. It may help to think of control keywords as boolean parameters.</h:p><h:p>Numeric parameters can describe values in molecules, forcefields or other
objects. Often the parameters will be refined or otherwise varied during the
calculation. Some parameters may be fixed at particular values or relaxed at different
stages in the calculation. Parameters can have errors, gradients and other indications
of uncertainty.</h:p><h:p>String/character parameters are often abbreviated in program input, and this
is supported through the<h:tt>regex</h:tt>and<h:tt>ignoreCase</h:tt>attributes. ?????</h:p><h:p>Parameters will usually be defined separately from the objects and use the<h:tt>ref</h:tt>attribute to reference them.</h:p><h:p>Parameters can be used to describe additional constraints. This will probably
require the development of a microlanguage and until then may use program-specific
mechanisms. A common approach will be to use an array of values (or objects) to
represent different input values for (parts of) the calculation. Thus a conformational
change could be specified by an array of several torsion angles.</h:p><h:p>A parameter will frequently have a<h:tt>dictRef</h:tt>pointing to a dictionary
which may have more information about how the parameter is to be used or the values
it can take.</h:p><h:p>The allowable content of<h:tt>parameter</h:tt>s may be shown by a "template"
in the<h:tt>appinfo</h:tt>; this is stil experimental.</h:p></h:div><h:div class="example" href="parameter1.xml"/>
<h:div class="summary">Constraint on a parameter.</h:div><h:div class="description">Semantics not yet finalised. We anticipate "fixed",
"none" and symbolic relationships to other parameters.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
Source
<xsd:element name="parameter" id="el.parameter"><xsd:annotation><xsd:documentation><h:div class="summary">A parameter describing the computation.</h:div><h:div class="description"><h:p>A parameter is a broad concept and can describe numeric quantities, objects,
keywords, etc. The distinction between keywords and parameters is often fuzzy.
("MINIM" might mean "minimize", while "MINIM=3" might require three iterations
to be run. It may help to think of control keywords as boolean parameters.</h:p><h:p>Numeric parameters can describe values in molecules, forcefields or other
objects. Often the parameters will be refined or otherwise varied during the
calculation. Some parameters may be fixed at particular values or relaxed at different
stages in the calculation. Parameters can have errors, gradients and other indications
of uncertainty.</h:p><h:p>String/character parameters are often abbreviated in program input, and this
is supported through the<h:tt>regex</h:tt>and<h:tt>ignoreCase</h:tt>attributes. ?????</h:p><h:p>Parameters will usually be defined separately from the objects and use the<h:tt>ref</h:tt>attribute to reference them.</h:p><h:p>Parameters can be used to describe additional constraints. This will probably
require the development of a microlanguage and until then may use program-specific
mechanisms. A common approach will be to use an array of values (or objects) to
represent different input values for (parts of) the calculation. Thus a conformational
change could be specified by an array of several torsion angles.</h:p><h:p>A parameter will frequently have a<h:tt>dictRef</h:tt>pointing to a dictionary
which may have more information about how the parameter is to be used or the values
it can take.</h:p><h:p>The allowable content of<h:tt>parameter</h:tt>s may be shown by a "template"
in the<h:tt>appinfo</h:tt>; this is stil experimental.</h:p></h:div><h:div class="example" href="parameter1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="property"/><xsd:element ref="expression"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="1"><xsd:element ref="gradient"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="value"><xsd:annotation><xsd:documentation><h:div class="specific">This is a shorthand for a single scalar value of the
parameter. It should only be used with the<h:tt>ref</h:tt>attribute as it inherits all the dataTyping of the referenced element. It must not be used for defining new parameters as it has no mechanism for units and dataTyping. [This may change?].</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="constraint"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>Used to define concepts such as independent and dependent
variables</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element property
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for a property.</h:div><h:div class="description"><h:tt>property</h:tt>can contain one or more children, usually<h:tt>scalar</h:tt>,<h:tt>array</h:tt>or<h:tt>matrix</h:tt>. The<h:tt>dictRef</h:tt>attribute is
required, even if there is a single scalar child with the same dictRef. The
property may have a different dictRef from the child, thus providing an extension
mechanism.<h:p>Properties may have a<h:tt>state</h:tt>attribute to distinguish the state of
matter</h:p></h:div><h:div class="example" href="property1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="property" id="el.property"><xsd:annotation><xsd:documentation><h:div class="summary">A container for a property.</h:div><h:div class="description"><h:tt>property</h:tt>can contain one or more children, usually<h:tt>scalar</h:tt>,<h:tt>array</h:tt>or<h:tt>matrix</h:tt>. The<h:tt>dictRef</h:tt>attribute is
required, even if there is a single scalar child with the same dictRef. The
property may have a different dictRef from the child, thus providing an extension
mechanism.<h:p>Properties may have a<h:tt>state</h:tt>attribute to distinguish the state of
matter</h:p></h:div><h:div class="example" href="property1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">Semantics are not yet controlled but could include
thermochemistry, kinetics or other common properties.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="state"/></xsd:complexType></xsd:element>
Element metadataList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A general container for metadata elements.</h:div><h:div class="description">MetadataLists can have local roles (e.g. a bibliographic reference could be a single meteadatList with, say, 3-6 components). The role attribute is used in an uncontrolled manner for this. MetadataLists can also be nested, but metadata and metadataList children should not occur on the same level of the hierarchy.</h:div><h:div class="example" href="metadata1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="metadataList" id="el.metadataList"><xsd:annotation><xsd:documentation><h:div class="summary">A general container for metadata elements.</h:div><h:div class="description">MetadataLists can have local roles (e.g. a bibliographic reference could be a single meteadatList with, say, 3-6 components). The role attribute is used in an uncontrolled manner for this. MetadataLists can also be nested, but metadata and metadataList children should not occur on the same level of the hierarchy.</h:div><h:div class="example" href="metadata1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadataList"/><xsd:element ref="metadata"/></xsd:choice><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
Element metadata
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A general container for metadata.</h:div><h:div class="description"><h:p>A general container for metadata, including at least
Dublin Core (DC) and CML-specific metadata</h:p><h:p>In its simple form each element provides a name and content in a similar
fashion to the<h:tt>meta</h:tt>element in HTML.<h:tt>metadata</h:tt>may have simpleContent
(i.e. a string for adding further information - this is not controlled).</h:p></h:div><h:div class="example" href="metadata1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The metadata type.</h:div><h:div class="description">This is likely to be the Dublin Core
name or something similar. The use of "type" is an infelicitous
misnomer and we shall try to remove it.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="metadata" id="el.metadata"><xsd:annotation><xsd:documentation><h:div class="summary">A general container for metadata.</h:div><h:div class="description"><h:p>A general container for metadata, including at least
Dublin Core (DC) and CML-specific metadata</h:p><h:p>In its simple form each element provides a name and content in a similar
fashion to the<h:tt>meta</h:tt>element in HTML.<h:tt>metadata</h:tt>may have simpleContent
(i.e. a string for adding further information - this is not controlled).</h:p></h:div><h:div class="example" href="metadata1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="content"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><!-- this creates an attribute of name "name" --><xsd:attributeGroup ref="metadataType"/><xsd:attributeGroup ref="title"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element gradient
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A gradient.</h:div><h:div class="description">A container for a quantity or quantities representing the
gradient of other quantities. At present just takes a scalar child.</h:div><h:div class="example" href="gradient1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="gradient" id="el.gradient"><xsd:annotation><xsd:documentation><h:div class="summary">A gradient.</h:div><h:div class="description">A container for a quantity or quantities representing the
gradient of other quantities. At present just takes a scalar child.</h:div><h:div class="example" href="gradient1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="property"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element operator
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An operator within an expression.</h:div><h:div class="description">Experimental. An operator acts on one or more arguments (at present the number is fixed by the type). The formulation is reverse Polish so the result (with its dataType) is put on a stack for further use.</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="operator" id="el.operator"><xsd:annotation><xsd:documentation><h:div class="summary">An operator within an expression.</h:div><h:div class="description">Experimental. An operator acts on one or more arguments (at present the number is fixed by the type). The formulation is reverse Polish so the result (with its dataType) is put on a stack for further use.</h:div><h:div class="example" href="potential1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="type"/></xsd:complexType></xsd:element>
Element bondArray
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for a number of bonds.</h:div><h:div class="description">_bondArray_ is a child of _molecule_ and contains _bond_ information. There are two strategies:<h:ul><h:li>Create individual<h:tt>bond</h:tt>elements under<h:tt>bondArray</h:tt>(in any order). This gives the greatest flexibility but is the most verbose.</h:li><h:li>Create<h:tt>*Array</h:tt>attributes (e.g. of<h:tt>orderArrayType</h:tt>under<h:tt>bondArray</h:tt>. This requires all arrays to be of identical lengths with explicit values for all bonds in every array. This is NOT suitable for complexType bond children such as _bondStereo_ nor can IDs be added to bonds.. It also cannot be checked as easily by schema- and schematron validation. The _atomRef1Array_ and _atomRef2Array_ attributes are then mandatory. It is allowed (though not yet recommended) to add _*Array_ children such as _floatArray_</h:li></h:ul><h:p>The attributes are directly related to the scalar attributes under _atom_ which should be consulted for more info.</h:p></h:div><h:div class="example" href="bondArray1.xml"><h:p>Example - these are exactly equivalent representations</h:p></h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bondArray" id="el.bondArray"><xsd:annotation><xsd:documentation><h:div class="summary">A container for a number of bonds.</h:div><h:div class="description">_bondArray_ is a child of _molecule_ and contains _bond_ information. There are two strategies:<h:ul><h:li>Create individual<h:tt>bond</h:tt>elements under<h:tt>bondArray</h:tt>(in any order). This gives the greatest flexibility but is the most verbose.</h:li><h:li>Create<h:tt>*Array</h:tt>attributes (e.g. of<h:tt>orderArrayType</h:tt>under<h:tt>bondArray</h:tt>. This requires all arrays to be of identical lengths with explicit values for all bonds in every array. This is NOT suitable for complexType bond children such as _bondStereo_ nor can IDs be added to bonds.. It also cannot be checked as easily by schema- and schematron validation. The _atomRef1Array_ and _atomRef2Array_ attributes are then mandatory. It is allowed (though not yet recommended) to add _*Array_ children such as _floatArray_</h:li></h:ul><h:p>The attributes are directly related to the scalar attributes under _atom_ which should be consulted for more info.</h:p></h:div><h:div class="example" href="bondArray1.xml"><h:p>Example - these are exactly equivalent representations</h:p></h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice><xsd:element ref="bond" maxOccurs="unbounded"/><xsd:element ref="array" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="bondIDArray"/><xsd:attributeGroup ref="atomRef1Array"/><xsd:attributeGroup ref="atomRef2Array"/><xsd:attributeGroup ref="orderArray"/></xsd:complexType></xsd:element>
Element bond
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A bond between atoms, or between atoms and bonds.</h:div><h:div class="description">_bond_ is a child of _bondArray_ and contains bond information. Bond must refer to at least two atoms (normally using _atomRefs2_) but may also refer to more for multicentre bonds. Bond is often EMPTY but may contain _electron_, _length_ or _bondStereo_ elements.</h:div><h:div class="example" href="bond1.xml"/>
<h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bond" id="el.bond"><xsd:annotation><xsd:documentation><h:div class="summary">A bond between atoms, or between atoms and bonds.</h:div><h:div class="description">_bond_ is a child of _bondArray_ and contains bond information. Bond must refer to at least two atoms (normally using _atomRefs2_) but may also refer to more for multicentre bonds. Bond is often EMPTY but may contain _electron_, _length_ or _bondStereo_ elements.</h:div><h:div class="example" href="bond1.xml"/><!--
<h:div class="example" href="bond2.xml"></h:div>
--></xsd:documentation><xsd:documentation><h:div class="validation" href="cmlCore.val.bond.xml"/></xsd:documentation><xsd:appinfo><comment xmlns="">Validate Bonds</comment><template match="bond" id="val-bond" xmlns=""><comment>Atom Refs for 2-atom bond</comment><variable name="at1" select="substring-before(normalize-space(@atomRefs2),' ')"/><variable name="at2" select="substring-after(normalize-space(@atomRefs2),' ')"/><comment>Are atoms distinct?</comment><if test="$at1 = $at2"><call-template name="error"><with-param name="error">BOND (<value-of select="@id"/>): ATOMS not distinct:<value-of select="$at1"/></with-param></call-template></if><comment>Do both atoms exist in current molecule context?</comment><if test="not(key('atoms', $at1))"><call-template name="error"><with-param name="error">BOND (<value-of select="@id"/>): ATOMREF not found:<value-of select="$at1"/></with-param></call-template></if><if test="not(key('atoms', $at2))"><call-template name="error"><with-param name="error">BOND (<value-of select="@id"/>): ATOMREF not found:<value-of select="$at2"/></with-param></call-template></if></template></xsd:appinfo></xsd:annotation><xsd:complexType id="bond.content.id"><xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="bondType"/><xsd:element ref="electron"><xsd:annotation><xsd:documentation><h:div class="summary">One or more electrons associated with the bond.</h:div><h:div class="description">The _bondRef_ on the _electron_ should point to the id on the bond. We may relax this later and allow reference by context.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="bondStereo"><xsd:annotation><xsd:documentation><h:div class="summary">The stereo convention for the bond.</h:div><h:div class="general">only one convention allowed.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice></xsd:choice><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="atomRefs2"/><xsd:attributeGroup ref="atomRefs"><xsd:annotation><xsd:documentation><h:div class="specific">This is designed for multicentre bonds (as in delocalised systems or electron-deficient centres. The semantics are experimental at this stage. As an example, a B-H-B bond might be described as
<bond atomRefs="b1 h2 b2"/.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="bondRefs"><xsd:annotation><xsd:documentation><h:div class="specific">This is designed for pi-bonds and other systems where formal valence bonds are not drawn to atoms. The semantics are experimental at this stage. As an example, a Pt-|| bond (as the Pt-ethene bond in Zeise's salt) might be described as <bond atomRefs="pt1" bondRefs="b32"/.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="order"/></xsd:complexType></xsd:element>
Element bondType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of a bond.</h:div><h:div class="description">Bond types are used to describe the behaviour
of bonds in forcefields, functional groups, reactions and many other
domains. They are not as well formalised as atomTypes and we provide
less semantic support. BondTypes are referred to by their mandatory
_name_ attribute.</h:div><h:div class="example" href="bondType1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bondType" id="el.bondType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of a bond.</h:div><h:div class="description">Bond types are used to describe the behaviour
of bonds in forcefields, functional groups, reactions and many other
domains. They are not as well formalised as atomTypes and we provide
less semantic support. BondTypes are referred to by their mandatory
_name_ attribute.</h:div><h:div class="example" href="bondType1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="molecule"/><xsd:element ref="bond"/><xsd:element ref="label"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="array"/><xsd:element ref="matrix"/><xsd:element ref="property"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="name"><xsd:annotation><xsd:documentation><h:div class="specific">The bondType name. The name will usually be namespaced as 'gulp:si', 'tripos:c.3', etc. It must occur except when the ref attribute is given.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element electron
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An electron.</h:div><h:div class="description">Since there is very little use of electrons in current chemical information this is a fluid concept. I expect it to be used for electron counting, input and output of theochem operations, descriptions of orbitals, spin states, oxidation states, etc. Electrons can be associated with atoms, bonds and combinations of these. At present there is no hardcoded semantics. However, _atomRef_ and similar attributes can be used to associate electrons with atoms or bond.</h:div><h:div class="example" href="electron1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="electron" id="el.electron"><xsd:annotation><xsd:documentation><h:div class="summary">An electron.</h:div><h:div class="description">Since there is very little use of electrons in current chemical information this is a fluid concept. I expect it to be used for electron counting, input and output of theochem operations, descriptions of orbitals, spin states, oxidation states, etc. Electrons can be associated with atoms, bonds and combinations of these. At present there is no hardcoded semantics. However, _atomRef_ and similar attributes can be used to associate electrons with atoms or bond.</h:div><h:div class="example" href="electron1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="atomRef"/><xsd:attributeGroup ref="atomRefs"/><xsd:attributeGroup ref="bondRef"/><xsd:attributeGroup ref="bondRefs"/><xsd:attributeGroup ref="count"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element bondStereo
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container supporting cis trans wedge hatch and other stereochemistry.</h:div><h:div class="description"><h:p>An explict list of atomRefs must be given, or it must be a child of<h:tt>bond</h:tt>. There are no implicit conventions such as E/Z. This will be extended to other types of stereochemistry.</h:p><h:p>At present the following are supported:</h:p><h:ul><h:li>No atomRefs attribute.<h:b>Deprecated, but probably unavoidable</h:b>.
This must be a child of<h:tt>bond</h:tt>where it picks up the two atomRefs
in the<h:tt>atomRefs2</h:tt>attribute. Possible values are C/T (which only makes sense
if there is exactly one ligand at each end of the bond) and W/H. The latter
should be raplaced by<h:tt>atomParity</h:tt>wherever possible. Note that W/H makes
no sense without 2D atom coordinates.</h:li><h:li><h:b>atomRefs4 attribute</h:b>. The 4 atoms represent a cis or trans configuration.
This may or may not be a child of<h:tt>bond</h:tt>; if so the second and third atomRefs
should be identical with the two atomRefs in the bond. This structure can be used
to guide processors in processing stereochemistry and is recommended, since there is
general agreement on the semantics. The semantics of<h:tt>bondStereo</h:tt>not related to
bonds is less clear (e.g. cumulenes, substituted ring nuclei) etc.It is
currently an error to have more than one<h:tt>bondStereo</h:tt>referring to the same ordered
4-atom list</h:li><h:li><h:b>atomRefs attribute</h:b>. There are other stereochemical conventions such as cis/trans
for metal complexes which require a variable number of reference atoms. This allows
users to create their own - at present we do not see CML creating exhaustive tables.
For example cis/trans square-planar complexes might require 4 (or 5) atoms for their
definition, octahedral 6 or 7, etc. In principle this is very powerful and could
supplement or replace the use of<h:i>cis-</h:i>,<h:i>mer-</h:i>, etc.</h:li></h:ul><h:p>the<h:tt>atomRefs</h:tt>and<h:tt>atomRefs4</h:tt>attributes cannot be used
simultaneously.</h:p></h:div><h:div class="example" href="bondStereo1.xml"/>
<h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The value of an element with a _convention_.</h:div><h:div class="description">When convention is used this attribute must be present and element content must be empty.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bondStereo" id="el.bondStereo"><xsd:annotation><xsd:documentation><h:div class="summary">A container supporting cis trans wedge hatch and other stereochemistry.</h:div><h:div class="description"><h:p>An explict list of atomRefs must be given, or it must be a child of<h:tt>bond</h:tt>. There are no implicit conventions such as E/Z. This will be extended to other types of stereochemistry.</h:p><h:p>At present the following are supported:</h:p><h:ul><h:li>No atomRefs attribute.<h:b>Deprecated, but probably unavoidable</h:b>.
This must be a child of<h:tt>bond</h:tt>where it picks up the two atomRefs
in the<h:tt>atomRefs2</h:tt>attribute. Possible values are C/T (which only makes sense
if there is exactly one ligand at each end of the bond) and W/H. The latter
should be raplaced by<h:tt>atomParity</h:tt>wherever possible. Note that W/H makes
no sense without 2D atom coordinates.</h:li><h:li><h:b>atomRefs4 attribute</h:b>. The 4 atoms represent a cis or trans configuration.
This may or may not be a child of<h:tt>bond</h:tt>; if so the second and third atomRefs
should be identical with the two atomRefs in the bond. This structure can be used
to guide processors in processing stereochemistry and is recommended, since there is
general agreement on the semantics. The semantics of<h:tt>bondStereo</h:tt>not related to
bonds is less clear (e.g. cumulenes, substituted ring nuclei) etc.It is
currently an error to have more than one<h:tt>bondStereo</h:tt>referring to the same ordered
4-atom list</h:li><h:li><h:b>atomRefs attribute</h:b>. There are other stereochemical conventions such as cis/trans
for metal complexes which require a variable number of reference atoms. This allows
users to create their own - at present we do not see CML creating exhaustive tables.
For example cis/trans square-planar complexes might require 4 (or 5) atoms for their
definition, octahedral 6 or 7, etc. In principle this is very powerful and could
supplement or replace the use of<h:i>cis-</h:i>,<h:i>mer-</h:i>, etc.</h:li></h:ul><h:p>the<h:tt>atomRefs</h:tt>and<h:tt>atomRefs4</h:tt>attributes cannot be used
simultaneously.</h:p></h:div><h:div class="example" href="bondStereo1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="stereoType"><xsd:attributeGroup ref="atomRefs4"/><xsd:attributeGroup ref="atomRefArray"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="conventionValue"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element crystal
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A crystallographic cell.</h:div><h:div class="description">Required if fractional coordinates are provided for
a molecule. Originally there were precisely SIX child<h:tt>scalar</h:tt>s to represent
the cell lengths and angles in that order. There are no default values; the
spacegroup is also included. This is now deprecated and replaced by cellParameter</h:div><h:div class="curation">2006-03-06 PMR: added cellParameter child</h:div><h:div class="example" href="crystal1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The number of molecules per cell.</h:div><h:div class="description">Molecules are defined as the _molecule_ which directly contains the _crystal_ element.</h:div>
Source
<xsd:element name="crystal" id="el.crystal"><xsd:annotation><xsd:documentation><h:div class="summary">A crystallographic cell.</h:div><h:div class="description">Required if fractional coordinates are provided for
a molecule. Originally there were precisely SIX child<h:tt>scalar</h:tt>s to represent
the cell lengths and angles in that order. There are no default values; the
spacegroup is also included. This is now deprecated and replaced by cellParameter</h:div><h:div class="curation">2006-03-06 PMR: added cellParameter child</h:div><h:div class="example" href="crystal1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:annotation><xsd:documentation><h:div class="description">OLD STYLE: All 6 cell parameters must be given, even where
angles are fixed by symmetry. The order is fixed as a,b,c,alpha,beta,gamma
and software can neglect any title or dictRef attributes. Error estimates
can be given if required. Any units can be used, but the defaults are
Angstrom (10^-10 m) and degrees.</h:div><h:div class="description">NEW STYLE: Two cellParameter children are given</h:div></xsd:documentation></xsd:annotation><xsd:choice minOccurs="0" maxOccurs="1"><xsd:element ref="scalar" minOccurs="6" maxOccurs="6"/><xsd:element ref="cellParameter" minOccurs="1" maxOccurs="2"/></xsd:choice><xsd:element ref="symmetry" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="z"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element cellParameter
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A set of 3 cell parameters.</h:div><h:div class="description">Either 3 lengths or 3 angles.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="cellParameter" id="el.cellParameter"><xsd:annotation><xsd:documentation><h:div class="summary">A set of 3 cell parameters.</h:div><h:div class="description">Either 3 lengths or 3 angles.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="vector3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="cellParameterType"/><xsd:attributeGroup ref="cellParameterError"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element symmetry
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Molecular, crystallographic or other symmetry.</h:div><h:div class="description"><h:p><h:tt>symmetry</h:tt>provides a label and/or symmetry operations for molecules
or crystals. Point and spacegroups can be specified by strings, though these are not
enumerated, because of variability in syntax (spaces, case-sensitivity, etc.),
potential high symmetries (e.g. TMV disk is D17) and
non-standard spacegroup settings. Provision is made for explicit symmetry operations
through <matrix> child elements.</h:p><h:p>By default the axes of symmetry are defined by the symbol - thus C2v requires
z to be the unique axis, while P21/c requires b/y. Spacegroups imply the semantics
defined in International Tables for Crystallography, (Int Union for Cryst., Munksgaard).
Point groups are also defined therein.</h:p><h:p>The element may also be used to give a label for the symmetry species (irreducible
representation) such as "A1u" for a vibration or orbital.</h:p><h:p>The matrices should be 3x3 for point group operators and 3x4 for spacegroup operators.
The use of crystallographic notation ("x,1/2+y,-z") is not supported - this would
be <matrix>1 0 0 0.0 0 1 0 0.5 0 0 1 0.0<matrix>.</h:p><h:p>The default convention for point group symmetry is<h:tt>Schoenflies</h:tt>and for
spacegroups is "H-M". Other conventions (e.g. "Hall") must be specfied through
the<h:tt>convention</h:tt>attribute.</h:p><h:p>This element implies that the Cartesians or fractional coordinates in a molecule
are oriented appropriately. In some cases it may be useful to specify the symmetry of
an arbitarily oriented molecule and the <molecule> element has the attribute<h:tt>symmetryOriented</h:tt>for this purpose.</h:p><h:p>It may be better to use transform3 to hold the symmetry as they have fixed shape and
have better defined mathematical operators.</h:p></h:div><h:div class="example" href="symmetry1.xml"/><h:div class="curation">2005-11-03 PMR. Added transform3 as children.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A symmetry species.</h:div><h:div class="description">No fixed semantics, though we may provide a controlled-extensible list in the future.</h:div>
<h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div>
<h:div class="summary">A point group.</h:div><h:div class="description">No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future.</h:div>
<h:div class="summary">A space group.</h:div><h:div class="description">No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="symmetry" id="el.symmetry"><xsd:annotation><xsd:documentation><h:div class="summary">Molecular, crystallographic or other symmetry.</h:div><h:div class="description"><h:p><h:tt>symmetry</h:tt>provides a label and/or symmetry operations for molecules
or crystals. Point and spacegroups can be specified by strings, though these are not
enumerated, because of variability in syntax (spaces, case-sensitivity, etc.),
potential high symmetries (e.g. TMV disk is D17) and
non-standard spacegroup settings. Provision is made for explicit symmetry operations
through <matrix> child elements.</h:p><h:p>By default the axes of symmetry are defined by the symbol - thus C2v requires
z to be the unique axis, while P21/c requires b/y. Spacegroups imply the semantics
defined in International Tables for Crystallography, (Int Union for Cryst., Munksgaard).
Point groups are also defined therein.</h:p><h:p>The element may also be used to give a label for the symmetry species (irreducible
representation) such as "A1u" for a vibration or orbital.</h:p><h:p>The matrices should be 3x3 for point group operators and 3x4 for spacegroup operators.
The use of crystallographic notation ("x,1/2+y,-z") is not supported - this would
be <matrix>1 0 0 0.0 0 1 0 0.5 0 0 1 0.0<matrix>.</h:p><h:p>The default convention for point group symmetry is<h:tt>Schoenflies</h:tt>and for
spacegroups is "H-M". Other conventions (e.g. "Hall") must be specfied through
the<h:tt>convention</h:tt>attribute.</h:p><h:p>This element implies that the Cartesians or fractional coordinates in a molecule
are oriented appropriately. In some cases it may be useful to specify the symmetry of
an arbitarily oriented molecule and the <molecule> element has the attribute<h:tt>symmetryOriented</h:tt>for this purpose.</h:p><h:p>It may be better to use transform3 to hold the symmetry as they have fixed shape and
have better defined mathematical operators.</h:p></h:div><h:div class="example" href="symmetry1.xml"/><h:div class="curation">2005-11-03 PMR. Added transform3 as children.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="matrix" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="transform3" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="pointGroup"/><xsd:attributeGroup ref="spaceGroup"/><xsd:attributeGroup ref="irreducibleRepresentation"/><xsd:attributeGroup ref="number"><xsd:annotation><xsd:documentation><h:div class="specific">The rotational symmetry number. Used for calculation of entropy, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element transform3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A transform in 3-space.</h:div><h:div class="description">A 3-D transform. Conventionally a 4x4 matrix.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="transform3" id="el.transform3"><xsd:annotation><xsd:documentation><h:div class="summary">A transform in 3-space.</h:div><h:div class="description">A 3-D transform. Conventionally a 4x4 matrix.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="matrix44Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element formula
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A molecular formula.</h:div><h:div class="description"><h:p>It is
defined by<h:tt>atomArray</h:tt>s each with a list of elementTypes and their
counts (or default=1). All other information in the<h:tt>atomArray</h:tt>is ignored.<h:tt>formula</h:tt>are nestable so that aggregates (e.g. hydrates,
salts, etc.) can be described. CML does not require that formula information
is consistent with (say) crystallographic information; this allows for
experimental variance.</h:p><h:p>An alternative briefer representation is also available through the<h:tt>concise</h:tt>. This must include whitespace round all elements and
their counts, which must be explicit.</h:p><h:p>2005-10-16. The semantics are now the following. A formula must have one or both:<h:ul><h:li>A concise attribute</h:li>A single atomArray child, using array format.</h:ul>it must also have a formalCharge attribute if atomArray is used and the charge is non-zero.</h:p><h:p>The concise, formalCharge and atomArrary information must always be consistent and software should
throw an error if not.</h:p><h:p>Until now there was no way of holding inline formula other than concise (although JUMBO5.0 is
capable of reading them). We now extend formula.xsd to incorporate this through the attribute
"inline" which requires the use of the "convention" attribute. The contents of inline are
purely textual. It can be used with or without atomArray or concise but there is no
guarantee that it can be interpreted as a meaningful chemical formula or that there is consistency.
In some cases a document supplies several formula representations (e.g. the IUCr's CIF). In this
case a molecule (or crystal) element might contain several formula children. The semantics of which
to use are application dependent.</h:p></h:div><h:div class="example" href="formula1.xml"/>
<h:div class="summary">A concise formula.</h:div><h:div class="general">The string represents an (unstructured) formula i.e. no submolecules.
Recommended to use the format "H 2 O 1", etc.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">An inline representation of the object.</h:div><h:div class="general">This can represent a wide range of information from formal serialization
as ASCII through to domain-specific textual representations. It will often be used in conjunction
with the "convention" attribute. For example it could be used to represent IUPAC formula,
SMILES strings, TeX equations, etc. Characters should conforma to the XML character set,
and XML markup (lt and amp) should be escaped.<h:b>IT SHOULD NEVER BE USED FOR INLINE XML</h:b></h:div><h:div class="example" href="attributeGroups/inline.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="formula" id="el.formula"><xsd:annotation><xsd:documentation><h:div class="summary">A molecular formula.</h:div><h:div class="description"><h:p>It is
defined by<h:tt>atomArray</h:tt>s each with a list of elementTypes and their
counts (or default=1). All other information in the<h:tt>atomArray</h:tt>is ignored.<h:tt>formula</h:tt>are nestable so that aggregates (e.g. hydrates,
salts, etc.) can be described. CML does not require that formula information
is consistent with (say) crystallographic information; this allows for
experimental variance.</h:p><h:p>An alternative briefer representation is also available through the<h:tt>concise</h:tt>. This must include whitespace round all elements and
their counts, which must be explicit.</h:p><h:p>2005-10-16. The semantics are now the following. A formula must have one or both:<h:ul><h:li>A concise attribute</h:li>A single atomArray child, using array format.</h:ul>it must also have a formalCharge attribute if atomArray is used and the charge is non-zero.</h:p><h:p>The concise, formalCharge and atomArrary information must always be consistent and software should
throw an error if not.</h:p><h:p>Until now there was no way of holding inline formula other than concise (although JUMBO5.0 is
capable of reading them). We now extend formula.xsd to incorporate this through the attribute
"inline" which requires the use of the "convention" attribute. The contents of inline are
purely textual. It can be used with or without atomArray or concise but there is no
guarantee that it can be interpreted as a meaningful chemical formula or that there is consistency.
In some cases a document supplies several formula representations (e.g. the IUCr's CIF). In this
case a molecule (or crystal) element might contain several formula children. The semantics of which
to use are application dependent.</h:p></h:div><h:div class="example" href="formula1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="formula"/><xsd:element ref="atomArray"/></xsd:choice></xsd:choice><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="count"><xsd:annotation><xsd:documentation><h:div class="specific">Allows for fractional components.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="formalCharge"><xsd:annotation><xsd:documentation><h:div class="specific">The charge on the formula. Mandatory if non-zero
(i.e. cannot rely on concise)</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="concise"/><xsd:attributeGroup ref="inline"><xsd:annotation><xsd:documentation><h:div class="specific">An inline representation of the formula.
There are no controlled semantics and it need not be compatible with concise
or atomArray.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element identifier
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A structured identifier.</h:div><h:div class="description"><h:p>Supports compund identifiers such as IChI. At present uses the V0.9 IChI XML representation verbatim but will almost certainly change with future IChIs.</h:p><h:p>The inclusion of elements from other namespaces causes problems with validation. The content model is deliberately LAX but the actual elements in IChI will fail the validation as they are not declared in CML.</h:p>For simple scalar values the value attribute can be used with empty content. Where an identifier has several components a series of label elements can be used.</h:div><h:div class="curation">2003-07-10: Fixed count on identifier children..</h:div><h:div class="curation">2003-03-12: Added isotopic and atoms..</h:div><h:div class="example" href="identifier1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Indicates whether the structure is a tautomer.</h:div><h:div class="general">Currently used with IChI _identifier_ element. Semantics, vocabulary and usage are application-dependent.</h:div>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
<h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div>
Source
<xsd:element name="identifier" id="el.identifier"><xsd:annotation><xsd:documentation><h:div class="summary">A structured identifier.</h:div><h:div class="description"><h:p>Supports compund identifiers such as IChI. At present uses the V0.9 IChI XML representation verbatim but will almost certainly change with future IChIs.</h:p><h:p>The inclusion of elements from other namespaces causes problems with validation. The content model is deliberately LAX but the actual elements in IChI will fail the validation as they are not declared in CML.</h:p>For simple scalar values the value attribute can be used with empty content. Where an identifier has several components a series of label elements can be used.</h:div><h:div class="curation">2003-07-10: Fixed count on identifier children..</h:div><h:div class="curation">2003-03-12: Added isotopic and atoms..</h:div><h:div class="example" href="identifier1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><!-- to avoid problems as IChI structure is updated --><xsd:sequence maxOccurs="unbounded" minOccurs="0"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="value"/><xsd:attributeGroup ref="version"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="tautomeric"/></xsd:complexType></xsd:element>
Element join
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Command to join two groups.</h:div><h:div class="description">EXPERIMENTAL. join will normally use atomRefs2 to identify 2 R atoms
(i.e. elementType="R" that should be joined. The atoms to which the R atoms
are attached are then joined by a new bond and the R groups are then deleted. It is currently
an error if these atoms already have a connecting bond.</h:div><h:div class="curation">2006-05-20: PMR added.</h:div><h:div class="curation">2006-11-24: PMR deleted @left, @linkOnParent, @right,
@repeat.</h:div><h:div class="curation">2006-11-24: PMR modified content model</h:div><h:div class="curation">2006-11-24: PMR added @moleculeRefs2</h:div>
<h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">References to two different molecules.</h:div><h:div class="description">Available for any reference to molecules but
normally will be the normal reference attribute on the join element.
The order of molecules is preserved and may matter.</h:div><h:div class="curation">2006-11-24: PMR created</h:div>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="join" id="el.join"><xsd:annotation><xsd:documentation><h:div class="summary">Command to join two groups.</h:div><h:div class="description">EXPERIMENTAL. join will normally use atomRefs2 to identify 2 R atoms
(i.e. elementType="R" that should be joined. The atoms to which the R atoms
are attached are then joined by a new bond and the R groups are then deleted. It is currently
an error if these atoms already have a connecting bond.</h:div><h:div class="curation">2006-05-20: PMR added.</h:div><h:div class="curation">2006-11-24: PMR deleted @left, @linkOnParent, @right,
@repeat.</h:div><h:div class="curation">2006-11-24: PMR modified content model</h:div><h:div class="curation">2006-11-24: PMR added @moleculeRefs2</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div class="summary"/></xsd:documentation></xsd:annotation><xsd:sequence><!--
<xsd:any minOccurs="0" maxOccurs="unbounded"/>
--><xsd:element ref="angle"/><xsd:element ref="arg"/><xsd:element ref="label"/><xsd:element ref="length"/><xsd:element ref="metadataList"/><xsd:element ref="molecule"/><xsd:element ref="torsion"/></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="atomRefs2"/><xsd:attributeGroup ref="moleculeRefs2"/><xsd:attributeGroup ref="order"/></xsd:complexType></xsd:element>
Element length
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A length between two atoms.</h:div><h:div class="general">This is either an experimental measurement or used to build up internal coordinates (as in a z-matrix) (only one allowed). We expect to move length as a child of _molecule_ and remove it from here.</h:div><h:div class="example" href="length1.xml"/>
<h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="length" id="el.length"><xsd:annotation><xsd:documentation><h:div class="summary">A length between two atoms.</h:div><h:div class="general">This is either an experimental measurement or used to build up internal coordinates (as in a z-matrix) (only one allowed). We expect to move length as a child of _molecule_ and remove it from here.</h:div><h:div class="example" href="length1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:double"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="atomRefs2"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="errorValue"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="min"/><xsd:attributeGroup ref="max"/><xsd:attributeGroup ref="ref"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element torsion
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A torsion angle ("dihedral") between 4 distinct atoms.</h:div><h:div class="description"><h:p>The atoms need not be formally bonded. It can be used for:</h:p><h:ul><h:li>Recording experimentally determined torsion angles (e.g. in
a crystallographic paper).</h:li><h:li>Providing the torsion component for internal coordinates (e.g.
z-matrix).</h:li></h:ul><h:p>Note that the order of atoms is important.</h:p></h:div><h:div class="example" href="torsion1.xml"/><h:div class="curation">2006-02-07: PMR. Fixed torsionAngleUnits</h:div>
<h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Restricts units to radians or degrees.</h:div><h:div class="description"/>
Source
<xsd:element name="torsion" id="el.torsion"><xsd:annotation><xsd:documentation><h:div class="summary">A torsion angle ("dihedral") between 4 distinct atoms.</h:div><h:div class="description"><h:p>The atoms need not be formally bonded. It can be used for:</h:p><h:ul><h:li>Recording experimentally determined torsion angles (e.g. in
a crystallographic paper).</h:li><h:li>Providing the torsion component for internal coordinates (e.g.
z-matrix).</h:li></h:ul><h:p>Note that the order of atoms is important.</h:p></h:div><h:div class="example" href="torsion1.xml"/><h:div class="curation">2006-02-07: PMR. Fixed torsionAngleUnits</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="torsionAngleType"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="atomRefs4"/><xsd:attributeGroup ref="angleUnits"/><xsd:attributeGroup ref="errorValue"/><xsd:attributeGroup ref="errorBasis"/><xsd:attributeGroup ref="min"/><xsd:attributeGroup ref="max"/><xsd:attributeGroup ref="ref"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element list
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A generic container with no implied semantics.</h:div><h:div class="description">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.</h:div><h:div class="example" href="list1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="list" id="el.list"><xsd:annotation><xsd:documentation><h:div class="summary">A generic container with no implied semantics.</h:div><h:div class="description">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.</h:div><h:div class="example" href="list1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="type"/></xsd:complexType></xsd:element>
Element propertyList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more properties.</h:div><h:div class="description"><h:tt>propertyList</h:tt>can contain several properties.
These include (but are not limited to) observations, or numeric quantities.</h:div><h:div class="example" href="propertyList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="propertyList" id="el.propertyList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more properties.</h:div><h:div class="description"><h:tt>propertyList</h:tt>can contain several properties.
These include (but are not limited to) observations, or numeric quantities.</h:div><h:div class="example" href="propertyList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="property"/><xsd:element ref="propertyList"/><xsd:element ref="observation"/></xsd:choice><!-- <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>--></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
Element observation
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An observation or occurrence.</h:div><h:div class="description">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.</h:div><h:div class="example" href="observation1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="observation" id="el.observation"><xsd:annotation><xsd:documentation><h:div class="summary">An observation or occurrence.</h:div><h:div class="description">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.</h:div><h:div class="example" href="observation1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="count"/></xsd:complexType></xsd:element>
Element zMatrix
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A zMatrix.</h:div><h:div class="description">A container for<h:tt>length</h:tt>,<h:tt>angle</h:tt>and<h:tt>torsion</h:tt>, which must be arranged in the conventional zMatrix format.</h:div><h:div class="example" href="zMatrix1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="zMatrix" id="el.zMatrix"><xsd:annotation><xsd:documentation><h:div class="summary">A zMatrix.</h:div><h:div class="description">A container for<h:tt>length</h:tt>,<h:tt>angle</h:tt>and<h:tt>torsion</h:tt>, which must be arranged in the conventional zMatrix format.</h:div><h:div class="example" href="zMatrix1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="length"/><xsd:element ref="angle"/><xsd:element ref="torsion"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element atomParity
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The stereochemistry round an atom centre.</h:div><h:div class="description">It follows the convention of the MIF format,
and uses 4 distinct atoms to define the chirality. These can be any
atoms (though they are normally bonded to the current atom). There is
no default order and the order is defined by the atoms in the atomRefs4
attribute. If there are only 3 ligands, the current atom should be
included in the 4 atomRefs.<h:p>The value of the parity is a signed number. (It can only be
zero if two or more atoms are coincident or the configuration is
planar). The sign is the sign of the chiral volume created by the
four atoms (a1, a2, a3, a4):</h:p><h:pre>| 1 1 1 1 |
| x1 x2 x3 x4 |
| y1 y2 y3 y4 |
| z1 z2 z3 z4 |</h:pre><h:p>Note that<h:tt>atomParity</h:tt>cannot be used with the
*Array syntax for atoms.</h:p></h:div><h:div class="example" href="atomParity1.xml"/>
<h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="atomParity" id="el.atomParity"><xsd:annotation><xsd:documentation><h:div class="summary">The stereochemistry round an atom centre.</h:div><h:div class="description">It follows the convention of the MIF format,
and uses 4 distinct atoms to define the chirality. These can be any
atoms (though they are normally bonded to the current atom). There is
no default order and the order is defined by the atoms in the atomRefs4
attribute. If there are only 3 ligands, the current atom should be
included in the 4 atomRefs.<h:p>The value of the parity is a signed number. (It can only be
zero if two or more atoms are coincident or the configuration is
planar). The sign is the sign of the chiral volume created by the
four atoms (a1, a2, a3, a4):</h:p><h:pre>| 1 1 1 1 |
| x1 x2 x3 x4 |
| y1 y2 y3 y4 |
| z1 z2 z3 z4 |</h:pre><h:p>Note that<h:tt>atomParity</h:tt>cannot be used with the
*Array syntax for atoms.</h:p></h:div><h:div class="example" href="atomParity1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:double"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="atomRefs4"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element particle
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An object in space carrying a set of properties.</h:div><h:div class="description"><h:tt>particles</h:tt>have many of the characteristics of<h:tt>atom</h:tt>s
but without an atomic nucleus. It does not have an elementType and cannot be
involved in bonding, etc. It has coordinates, may carry charge and might have a
mass. It represents some aspect of a computational model and should not be used
for purely geometrical concepts such as centroid. Examples of particles are
"shells" (e.g. in GULP) which are linked to atoms for modelling polarizability
or lonepairs and approximations to multipoles. Properties such as charge, mass
should be scalar/array/matrix children.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div>
<h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
<h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
Source
<xsd:element name="particle" id="el.particle"><xsd:annotation><xsd:documentation><h:div class="summary">An object in space carrying a set of properties.</h:div><h:div class="description"><h:tt>particles</h:tt>have many of the characteristics of<h:tt>atom</h:tt>s
but without an atomic nucleus. It does not have an elementType and cannot be
involved in bonding, etc. It has coordinates, may carry charge and might have a
mass. It represents some aspect of a computational model and should not be used
for purely geometrical concepts such as centroid. Examples of particles are
"shells" (e.g. in GULP) which are linked to atoms for modelling polarizability
or lonepairs and approximations to multipoles. Properties such as charge, mass
should be scalar/array/matrix children.</h:div><!--
<h:div class="example" href="particle1.xml"></h:div>
--></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="type"><xsd:annotation><xsd:documentation><h:div class="specific">Used in a similar manner to<h:tt>atomType</h:tt>. Examples
might be "lonePair", "polarizable Oxygen", etc.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="x3"/><xsd:attributeGroup ref="y3"/><xsd:attributeGroup ref="z3"/></xsd:complexType></xsd:element>
Element vector3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A vector in 3-space.</h:div><h:div class="description">The vector may have magnitude but is not rooted on
any points (use line3).</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="vector3" id="el.vector3"><xsd:annotation><xsd:documentation><h:div class="summary">A vector in 3-space.</h:div><h:div class="description">The vector may have magnitude but is not rooted on
any points (use line3).</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="vector3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element abundance
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The abundance of an isotope.</h:div><h:div class="description">The abundance of an isotope in an isotopeList.
Values are expressed in percentages.</h:div><h:div class="example" href="isotope1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="abundance" id="el.abundance"><xsd:annotation><xsd:documentation><h:div class="summary">The abundance of an isotope.</h:div><h:div class="description">The abundance of an isotope in an isotopeList.
Values are expressed in percentages.</h:div><h:div class="example" href="isotope1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:double"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="min"/><xsd:attributeGroup ref="max"/><xsd:attributeGroup ref="units"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element action
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An action which might occur in scientific data or narrative.</h:div><h:div class="description">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. _action_ iself is normally a child of _actionList_.<h:p>The start, end and duration attributes should be interpreted as</h:p><h:ul><h:li>XSD dateTimes and XSD durations. This allows precise recording of time of day, etc, or duration after start of actionList. A<h:tt>convention="xsd"</h:tt>attribute should be used to enforce XSD.</h:li><h:li>a numerical value, with a units attribute linked to a dictionary.</h:li><h:li>a human-readable string (unlikely to be machine processable)</h:li></h:ul><h:p><h:tt>startCondition</h:tt>and<h:tt>endCondition</h:tt>values are not constrained, which allows XSL-like<h:tt>test</h:tt>attribute values. The semantics of the conditions are yet to be defined and at present are simply human readable.</h:p><h:p>The order of the<h:tt>action</h:tt>elements in the document may, but will not always, define
the order that they actually occur in.</h:p><h:p>A delay can be shown by an<h:tt>action</h:tt>with no content. Repeated actions or
actionLists are indicated through the count attribute.</h:p></h:div><h:div class="example" href="action1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="action" id="el.action"><xsd:annotation><xsd:documentation><h:div class="summary">An action which might occur in scientific data or narrative.</h:div><h:div class="description">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. _action_ iself is normally a child of _actionList_.<h:p>The start, end and duration attributes should be interpreted as</h:p><h:ul><h:li>XSD dateTimes and XSD durations. This allows precise recording of time of day, etc, or duration after start of actionList. A<h:tt>convention="xsd"</h:tt>attribute should be used to enforce XSD.</h:li><h:li>a numerical value, with a units attribute linked to a dictionary.</h:li><h:li>a human-readable string (unlikely to be machine processable)</h:li></h:ul><h:p><h:tt>startCondition</h:tt>and<h:tt>endCondition</h:tt>values are not constrained, which allows XSL-like<h:tt>test</h:tt>attribute values. The semantics of the conditions are yet to be defined and at present are simply human readable.</h:p><h:p>The order of the<h:tt>action</h:tt>elements in the document may, but will not always, define
the order that they actually occur in.</h:p><h:p>A delay can be shown by an<h:tt>action</h:tt>with no content. Repeated actions or
actionLists are indicated through the count attribute.</h:p></h:div><h:div class="example" href="action1.xml"/><!--
<h:div class="example" href="action2.xml"></h:div>
--></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="start"/><xsd:attributeGroup ref="startCondition"/><xsd:attributeGroup ref="duration"/><xsd:attributeGroup ref="end"/><xsd:attributeGroup ref="endCondition"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="actionOrder"/><xsd:attributeGroup ref="count"><xsd:annotation><xsd:documentation><h:div class="specific">Number of times the action should be repeated.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element actionList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for a group of actions.</h:div><h:div class="description"><h:tt>ActionList</h:tt>contains a series of<h:tt>action</h:tt>s or
nested<h:tt>actionList</h:tt>s.</h:div><h:div class="example" href="actionList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="actionList" id="el.actionList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for a group of actions.</h:div><h:div class="description"><h:tt>ActionList</h:tt>contains a series of<h:tt>action</h:tt>s or
nested<h:tt>actionList</h:tt>s.</h:div><h:div class="example" href="actionList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="start"/><xsd:attributeGroup ref="startCondition"/><xsd:attributeGroup ref="duration"/><xsd:attributeGroup ref="end"/><xsd:attributeGroup ref="endCondition"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="count"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="actionOrder"/></xsd:complexType></xsd:element>
Element alternative
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An alternative name for an entry.</h:div><h:div class="description">At present a child of _entry_ which represents an alternative string that refers to the concept. There is a partial controlled vocabulary in _alternativeType_ with values such as :<h:ul><h:li>synonym</h:li><h:li>acronym</h:li><h:li>abbreviation</h:li></h:ul></h:div><h:div class="example" href="alternative1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div>
Source
<xsd:element name="alternative" id="el.alternative"><xsd:annotation><xsd:documentation><h:div class="summary">An alternative name for an entry.</h:div><h:div class="description">At present a child of _entry_ which represents an alternative string that refers to the concept. There is a partial controlled vocabulary in _alternativeType_ with values such as :<h:ul><h:li>synonym</h:li><h:li>acronym</h:li><h:li>abbreviation</h:li></h:ul></h:div><h:div class="example" href="alternative1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="alternativeType"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element amount
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The amount of a substance.</h:div><h:div class="description">The<h:tt>units</h:tt>attribute is mandatory and
can be customised to support mass, volumes, moles, percentages, or ratios
(e.g. ppm).</h:div><h:div class="example" href="amount1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="amount" id="el.amount"><xsd:annotation><xsd:documentation><h:div class="summary">The amount of a substance.</h:div><h:div class="description">The<h:tt>units</h:tt>attribute is mandatory and
can be customised to support mass, volumes, moles, percentages, or ratios
(e.g. ppm).</h:div><h:div class="example" href="amount1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:double"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="units" id="att.amount.units"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element annotation
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A documentation container similar to annotation in XML Schema.</h:div><h:div class="description">A documentation container similar to<h:tt>annotation</h: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<h:tt>documentation</h:tt>and<h:tt>appinfo</h:tt>children will emerge in their correct position in the derived schema.<h:p>It is possible that this may develop as a useful tool for annotating components
of complex objects such as molecules.</h:p></h:div><h:div class="example" href="annotation1.xml"/>
<xsd:element name="annotation" id="el.annotation"><xsd:annotation><xsd:documentation><h:div class="summary">A documentation container similar to annotation in XML Schema.</h:div><h:div class="description">A documentation container similar to<h:tt>annotation</h: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<h:tt>documentation</h:tt>and<h:tt>appinfo</h:tt>children will emerge in their correct position in the derived schema.<h:p>It is possible that this may develop as a useful tool for annotating components
of complex objects such as molecules.</h:p></h:div><h:div class="example" href="annotation1.xml"/></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:complexType></xsd:element>
Element documentation
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Documentation in the annotation of an entry.</h:div><h:div class="description"><h:p>A container similar to<h:tt>documentation</h: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<h:tt>documentation</h:tt>and<h:tt>appinfo</h:tt>children will emerge in their correct position in the derived schema.</h:p><h:p>Do NOT confuse documentation with the description or the definition which are part of the content
of the dictionary</h:p><h:p>If will probably only be used when there is significant appinfo
in the entry or where the entry defines an XSD-like datatype of an element in the document.</h:p></h:div><h:div class="example" href="documentation1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="documentation" id="el.documentation"><xsd:annotation><xsd:documentation><h:div class="summary">Documentation in the annotation of an entry.</h:div><h:div class="description"><h:p>A container similar to<h:tt>documentation</h: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<h:tt>documentation</h:tt>and<h:tt>appinfo</h:tt>children will emerge in their correct position in the derived schema.</h:p><h:p>Do NOT confuse documentation with the description or the definition which are part of the content
of the dictionary</h:p><h:p>If will probably only be used when there is significant appinfo
in the entry or where the entry defines an XSD-like datatype of an element in the document.</h:p></h:div><h:div class="example" href="documentation1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/></xsd:complexType></xsd:element>
Element appinfo
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container similar to appinfo in XML Schema.</h:div><h:div class="description">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. See _annotation_ and _documentation_ for further information.</h:div><h:div class="example" href="appinfo1.xml"><h:p>An example in XSLT where an element _foo_ calls a bespoke template</h:p>.</h:div>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
Source
<xsd:element name="appinfo" id="el.appinfo"><xsd:annotation><xsd:documentation><h:div class="summary">A container similar to appinfo in XML Schema.</h:div><h:div class="description">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. See _annotation_ and _documentation_ for further information.</h:div><h:div class="example" href="appinfo1.xml"><h:p>An example in XSLT where an element _foo_ calls a bespoke template</h:p>.</h:div></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">Allows a processor to inspect the role of the appinfo and process accordingly.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element arrayList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A list of<tt xmlns="">array</tt>s or<tt xmlns="">list</tt>s.</h:div><h:div class="description"><h:p>A major use of arrayList is to contain data within rectangular tables. However there is no
absolute requirement and the table can have any shape. The<tt xmlns="">shape</tt>attribute hould be used
to assert rectangularity.</h:p></h:div><h:div class="example" href="arrayList1.xml"/><h:div class="curation">2006-11-03: created</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="arrayList" id="el.arrayList"><xsd:annotation><xsd:documentation><h:div class="summary">A list of<tt xmlns="">array</tt>s or<tt xmlns="">list</tt>s.</h:div><h:div class="description"><h:p>A major use of arrayList is to contain data within rectangular tables. However there is no
absolute requirement and the table can have any shape. The<tt xmlns="">shape</tt>attribute hould be used
to assert rectangularity.</h:p></h:div><h:div class="example" href="arrayList1.xml"/><h:div class="curation">2006-11-03: created</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="array"/><xsd:element ref="list"/></xsd:choice><xsd:attributeGroup ref="shape"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element atomicBasisFunction
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An atomicBasisFunction.</h:div><h:div class="description"><h:p>An atomic atomicBasisFunction which can be linked to atoms,
eigenvalues/vectors etc. Normally contained within _basisSet_</h:p><h:p>Normally these are atom-centered functions, but they can also serve as
"ghost" functions which are centered on points. These can be dummy atoms so
that the atomRef mechanism can still be used.</h:p><h:p>This information is required to interpret the eignevector components
and map them onto the atom list. However this mapping is normally implicit
in the program and so it may be necessary to generate<h:tt>basisSet</h:tt>information for some programs before XML technology can be automatically used
to link the components of the CCML document.</h:p></h:div><h:div class="example" href="atomicBasisFunction1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="atomicBasisFunction" id="el.atomicBasisFunction"><xsd:annotation><xsd:documentation><h:div class="summary">An atomicBasisFunction.</h:div><h:div class="description"><h:p>An atomic atomicBasisFunction which can be linked to atoms,
eigenvalues/vectors etc. Normally contained within _basisSet_</h:p><h:p>Normally these are atom-centered functions, but they can also serve as
"ghost" functions which are centered on points. These can be dummy atoms so
that the atomRef mechanism can still be used.</h:p><h:p>This information is required to interpret the eignevector components
and map them onto the atom list. However this mapping is normally implicit
in the program and so it may be necessary to generate<h:tt>basisSet</h:tt>information for some programs before XML technology can be automatically used
to link the components of the CCML document.</h:p></h:div><h:div class="example" href="atomicBasisFunction1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="1"><xsd:element ref="gradient"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="atomRef"><xsd:annotation><xsd:documentation><h:div class="specific">The atom owning this atomicBasisFunction.
This reference is required to tie the reported eigenvector components to
the list of atoms.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="n"/><xsd:attributeGroup ref="l"/><xsd:attributeGroup ref="m"><xsd:annotation><xsd:documentation><h:div class="specific">This is provided for completeness but we do not see
it being widely used and the symbolic representation (lm) is more valuable.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="symbol"><xsd:annotation><xsd:documentation><h:div class="specific">This is a local annotation of the ABF and unlikely to
be enumeratable. Thus a split s-orbital could have 3 ABFs with "s", "s'", "s''"
but they would all have lm="s".</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="lm"><xsd:annotation><xsd:documentation><h:div class="specific">This is a "standard" representation of the ABF, but
not enumerated until we decide whether it can be formalised. Examples are "px",
"dxy", etc. Note that d-orbitals and higher may be represented with redundant
ABFs, e.g. 6 d-orbitals. The more standard the representation, the more useful
this will be for searching.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element atomSet
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A set of references to atoms.</h:div><h:div class="description">An atomSet consists of a number of unique references to atoms throught their ids. atomSets need not be related to molecules (which are generally created by aggregation of explicit atoms). Two or more atomSets may reference the same atom, and atomSets may be empty.<h:p>atomSets have many potential uses such as:<h:ul><h:li>identifying functional groups</h:li><h:li>results of substructure matching</h:li><h:li>identifying atoms with particular roles in a calculation</h:li></h:ul></h:p><h:p>The atomSet may be referenced from elsewhere in the document and you are encouraged to use locally unique id attributes on atomSets.</h:p></h:div><h:div class="example" href="atomSet1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="atomSet" id="el.atomSet"><xsd:annotation><xsd:documentation><h:div class="summary">A set of references to atoms.</h:div><h:div class="description">An atomSet consists of a number of unique references to atoms throught their ids. atomSets need not be related to molecules (which are generally created by aggregation of explicit atoms). Two or more atomSets may reference the same atom, and atomSets may be empty.<h:p>atomSets have many potential uses such as:<h:ul><h:li>identifying functional groups</h:li><h:li>results of substructure matching</h:li><h:li>identifying atoms with particular roles in a calculation</h:li></h:ul></h:p><h:p>The atomSet may be referenced from elsewhere in the document and you are encouraged to use locally unique id attributes on atomSets.</h:p></h:div><h:div class="example" href="atomSet1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="atomRefArrayType"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="size"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element atomTypeList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more atomTypes.</h:div><h:div class="description">It can contain several atomTypes.</h:div><h:div class="example" href="atomTypeList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to a kpoint.</h:div><h:div class="description">Used by band, etc.</h:div><h:div class="curation">2006-01-21: PMR. Created</h:div>
<h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div>
<h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div>
Source
<xsd:element name="band" id="el.band"><xsd:annotation><xsd:documentation><h:div class="summary">A band or Brillouin zone.</h:div><h:div class="description">Not yet finalised.</h:div><h:div class="example" href="band1.xml"/><h:div class="curation">2006-01-21: PMR. added kpointRef and deprecated kpointList.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="array" minOccurs="1" maxOccurs="1"><xsd:annotation><xsd:documentation><h:div class="summary">Band energies associated with this kpoint.</h:div><h:div class="description">The energy units must be given.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence><xsd:attributeGroup ref="kpoint"><xsd:annotation><xsd:documentation><h:div class="deprecated">kpoints should be described in
kpointList and referenced.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="kpointRef"/><xsd:attributeGroup ref="weight"/><xsd:attributeGroup ref="label"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element bandList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for bands.</h:div><h:div class="description">Experimental.</h:div><h:div class="example" href="band1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A container for one or more atomicBasisFunctions.</h:div><h:div class="description">This can contain several orbitals.</h:div><h:div class="example" href="basisSet1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="basisSet" id="el.basisSet"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more atomicBasisFunctions.</h:div><h:div class="description">This can contain several orbitals.</h:div><h:div class="example" href="basisSet1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="atomicBasisFunction"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
Element bondSet
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A set of references to bonds.</h:div><h:div class="description">An bondSet consists of a number of unique references to bonds throught their ids. bondSets need not be related to molecules (which are generally created by aggregation of explicit bonds). Two or more bondSets may reference the same bond, and bondSets may be empty.<h:p>bondSets have many potential uses such as:<h:ul><h:li>identifying functional groups</h:li><h:li>results of substructure matching</h:li><h:li>identifying bonds with particular roles in a calculation</h:li></h:ul></h:p><h:p>The bondSet may be referenced from elsewhere in the document and you are encouraged to use locally unique id attributes on bondSets.</h:p></h:div><h:div class="example" href="bondSet1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bondSet" id="el.bondSet"><xsd:annotation><xsd:documentation><h:div class="summary">A set of references to bonds.</h:div><h:div class="description">An bondSet consists of a number of unique references to bonds throught their ids. bondSets need not be related to molecules (which are generally created by aggregation of explicit bonds). Two or more bondSets may reference the same bond, and bondSets may be empty.<h:p>bondSets have many potential uses such as:<h:ul><h:li>identifying functional groups</h:li><h:li>results of substructure matching</h:li><h:li>identifying bonds with particular roles in a calculation</h:li></h:ul></h:p><h:p>The bondSet may be referenced from elsewhere in the document and you are encouraged to use locally unique id attributes on bondSets.</h:p></h:div><h:div class="example" href="bondSet1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="bondRefArrayType"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="size"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element bondTypeList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more bondTypes.</h:div><h:div class="description">_bondTypeList_ can contain several bondTypes.</h:div><h:div class="example" href="bondTypeList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="bondTypeList" id="el.bondTypeList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more bondTypes.</h:div><h:div class="description">_bondTypeList_ can contain several bondTypes.</h:div><h:div class="example" href="bondTypeList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="bondType"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element cml
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A general container for CML elements.</h:div><h:div class="description">Often the root of the CML (sub)document.
Has no explicit function but can serve to hold the dictionary and
namespace and version information, and is a useful tag to alert
CML processors
and search/XMLQuery tools that there is chemistry in the document.
Can contain any content, but usually a list of molecules and other
CML components. The fileId attribute can be used to preserve the origin
of the information, though metadat should also be used. Can be nested.</h:div><h:div class="example" href="cml1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Information identifying the name of a file or other resource.</h:div><h:div class="description">This allows an element (such as cml) to carry limited
information about provenance such as the name of the document used to provide the
content. It is not a complete solution but can help to protect a document becoming
separated from its external metadata. It is restricted to the basic XML character set
(printable ANSI) and whitespace (which should anyway be discouraged) is normalized to
single space (attribute values cannot carry newlines).
Quotation marks and other horrors (as used in some OS)
should be avoided.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div>
Source
<xsd:element name="cml" id="el.cml"><xsd:annotation><xsd:documentation><h:div class="summary">A general container for CML elements.</h:div><h:div class="description">Often the root of the CML (sub)document.
Has no explicit function but can serve to hold the dictionary and
namespace and version information, and is a useful tag to alert
CML processors
and search/XMLQuery tools that there is chemistry in the document.
Can contain any content, but usually a list of molecules and other
CML components. The fileId attribute can be used to preserve the origin
of the information, though metadat should also be used. Can be nested.</h:div><h:div class="example" href="cml1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="description">No specific restrictions..</h:div></xsd:documentation></xsd:annotation><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="fileId"/><xsd:attributeGroup ref="version"/></xsd:complexType></xsd:element>
Element complexObject
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An element to hold any combination of heterogeneous element children</h:div><h:div class="description">complexObject can be used as it stands but will often be extended by
schema definitions in dictionary entries.</h:div><h:div class="example" href="complexObject1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="complexObject" id="el.complexObject"><xsd:annotation><xsd:documentation><h:div class="summary">An element to hold any combination of heterogeneous element children</h:div><h:div class="description">complexObject can be used as it stands but will often be extended by
schema definitions in dictionary entries.</h:div><h:div class="example" href="complexObject1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element conditionList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more experimental conditions.</h:div><h:div class="description">This can contain several conditions. These include
(but are not limited to) intensive physical properties (temperature, pressure, etc.),
apparatus (test-tube, rotary evaporator, etc.).
Actions can be represented elsewhere by actionList and solvents or other
substances by substanceList.</h:div><h:div class="example" href="conditionList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="conditionList" id="el.conditionList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more experimental conditions.</h:div><h:div class="description">This can contain several conditions. These include
(but are not limited to) intensive physical properties (temperature, pressure, etc.),
apparatus (test-tube, rotary evaporator, etc.).
Actions can be represented elsewhere by actionList and solvents or other
substances by substanceList.</h:div><h:div class="example" href="conditionList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="scalar"/><xsd:element ref="list"/></xsd:choice><!-- <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>--></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
Element definition
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The definition for an entry.</h:div><h:div class="description">The definition should be a short nounal phrase defining the subject of the entry. Definitions should not include commentary, implementations, equations or formulae (unless the subject is one of these) or examples.<h: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.</h:p></h:div><h:div class="example" href="definition1.xml"><h:em>From the IUPAC Dictionary of Medicinal Chemistry</h:em><h:br/></h:div>
<xsd:element name="definition" id="el.definition"><xsd:annotation><xsd:documentation><h:div class="summary">The definition for an entry.</h:div><h:div class="description">The definition should be a short nounal phrase defining the subject of the entry. Definitions should not include commentary, implementations, equations or formulae (unless the subject is one of these) or examples.<h: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.</h:p></h:div><h:div class="example" href="definition1.xml"><h:em>From the IUPAC Dictionary of Medicinal Chemistry</h:em><h:br/></h:div></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence></xsd:complexType></xsd:element>
Element description
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Descriptive information.</h:div><h:div class="description">This can occur in objects which require textual comment such as entry.<h:p>Entries should have at least one separate<h:a href="el.definition">definition</h:a>s.<h:tt>description</h:tt>is then used for most of the other information, including
examples. The<h:tt>class</h:tt>attribute has an uncontrolled vocabulary and
can be used to clarify the purposes of the<h:tt>description</h:tt>elements.</h:p></h:div><h:div class="example" href="description1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="description" id="el.description"><xsd:annotation><xsd:documentation><h:div class="summary">Descriptive information.</h:div><h:div class="description">This can occur in objects which require textual comment such as entry.<h:p>Entries should have at least one separate<h:a href="el.definition">definition</h:a>s.<h:tt>description</h:tt>is then used for most of the other information, including
examples. The<h:tt>class</h:tt>attribute has an uncontrolled vocabulary and
can be used to clarify the purposes of the<h:tt>description</h:tt>elements.</h:p></h:div><h:div class="example" href="description1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="objectClass"/></xsd:complexType></xsd:element>
Element dictionary
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A dictionary.</h:div><h:div class="description">A dictionary is a container for _entry_ elements.
Dictionaries can also contain unit-related information.
The dictRef attribute on a dictionary 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 __dictRef__ attribute.</h:div><h:div class="example" href="dictionary1.xml"/><h:div class="curation">2005-12-15. PMR. added namespace
and dictionaryPrefix.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="dictionary" id="el.dictionary"><xsd:annotation><xsd:documentation><h:div class="summary">A dictionary.</h:div><h:div class="description">A dictionary is a container for _entry_ elements.
Dictionaries can also contain unit-related information.
The dictRef attribute on a dictionary 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 __dictRef__ attribute.</h:div><h:div class="example" href="dictionary1.xml"/><!--
<h:div class="example" href="dictionary2.xml">
<h:p>
<h:tt>dictionary</h:tt> can be used in an instance
document to reference the dictionary used. Example:</h:p></h:div>
--><h:div class="curation">2005-12-15. PMR. added namespace
and dictionaryPrefix.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="unitList" minOccurs="0" maxOccurs="unbounded"/><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="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="href"/><xsd:attributeGroup ref="namespace"/><xsd:attributeGroup ref="dictionaryPrefix"/></xsd:complexType></xsd:element>
Element unitList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for several unit entries.</h:div><h:div class="description">Usually forms the complete units dictionary
(along with metadata). Note: this used to hold both units and unitTypes
(though in separate files). This was unwieldy and unitTypeList has been
created to hold unitTypes. Implementers are recommended to change
any unitList/unitType to unitTypeList/unitType</h:div><h:div class="example" href="unitList1.xml"/><h:div class="curation">2005-12-15. PMR. added namespace
and dictionaryPrefix.</h:div><h:div class="curation">2005-12-17. PMR. added siNamespace .</h:div><h:div class="curation">2006-01-28. PMR. deprecated use for holding unitType.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div>
<h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Needed to differentiate the rather unhappy
polymorphism of unitList/unit and unitList/unitType.</h:div><h:div class="curation">2005-12-17 PMR: Added</h:div>
Source
<xsd:element name="unitList" id="el.unitList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for several unit entries.</h:div><h:div class="description">Usually forms the complete units dictionary
(along with metadata). Note: this used to hold both units and unitTypes
(though in separate files). This was unwieldy and unitTypeList has been
created to hold unitTypes. Implementers are recommended to change
any unitList/unitType to unitTypeList/unitType</h:div><h:div class="example" href="unitList1.xml"/><h:div class="curation">2005-12-15. PMR. added namespace
and dictionaryPrefix.</h:div><h:div class="curation">2005-12-17. PMR. added siNamespace .</h:div><h:div class="curation">2006-01-28. PMR. deprecated use for holding unitType.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="unitType" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="deprecated">2006-01-28: PMR. use unitTypeList.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="unit" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="unitListType"><xsd:annotation><xsd:documentation><h:div class="deprecated">2006-01-28: PMR. use unitTypeList.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="namespace"/><xsd:attributeGroup ref="siNamespace"/><xsd:attributeGroup ref="dictionaryPrefix"/><xsd:attributeGroup ref="href"><xsd:annotation><xsd:documentation><h:div class="specific">Maps dictRef prefix to the location of a dictionary. 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.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element unitType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of a scientific unit.</h:div><h:div class="description"><h: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.</h:p><h:p>Used within a unitList</h:p><h:p>Distinguish carefully from<h:a href="st.unitsType">unitsType</h:a>which is primarily used for attributes describing the units that elements
carry</h:p></h:div><h:div class="example" href="unitType1.xml"/><h:div class="curation">2006-02-06: PMR. Added preserve and symbol attributes.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/>
<h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div>
<h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="unitType" id="el.unitType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of a scientific unit.</h:div><h:div class="description"><h: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.</h:p><h:p>Used within a unitList</h:p><h:p>Distinguish carefully from<h:a href="st.unitsType">unitsType</h:a>which is primarily used for attributes describing the units that elements
carry</h:p></h:div><!--
<h:div class="example" href="unit2.xml"></h:div>
--><h:div class="example" href="unitType1.xml"/><!--
<h:div class="example" href="unitType2.xml"></h:div>
--><h:div class="curation">2006-02-06: PMR. Added preserve and symbol attributes.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="annotation"/><xsd:element ref="dimension" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="description" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="definition" minOccurs="0" maxOccurs="1"/></xsd:choice><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="parentSI"/><xsd:attributeGroup ref="abbreviation"/><xsd:attributeGroup ref="preserve"/><xsd:attributeGroup ref="symbol"/></xsd:complexType></xsd:element>
Element dimension
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A dimension supporting scientific unit.</h:div><h:div class="description">This will be primarily used within the definition of units.
Two dimensions are of the same type if their 'name' attributes are (case-sensitive)
identical. Dimensions of the same typecan be algebraically combined using the 'power' attributes.
Normally dimensions will be aggregated and cancelled algebraically, but the 'preserve'
attribute can be used to prevent this. Thus a velocity gradient over length can be
defined as:<h:pre><unitType id="a1" preserve="true" xmlns=""><dimension name="length" power="1"/><dimension name="time" power="-1"/><dimension name="length" power="-1"/></unitType></h:pre>whereas cancelling the dimensions would give:<h:pre><unitType id="a1" preserve="true" xmlns=""><dimension name="time" power="-1"/></unitType></h:pre></h:div><h:div class="example" href="dimension1.xml"/><h:div class="example" href="dimension2.xml"/>
<h:div class="summary">The basis of the dimension.</h:div><h:div class="description">Normally taken from the seven SI types but possibly expandable.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
<h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div>
Source
<xsd:element name="dimension" id="el.dimension"><xsd:annotation><xsd:documentation><h:div class="summary">A dimension supporting scientific unit.</h:div><h:div class="description">This will be primarily used within the definition of units.
Two dimensions are of the same type if their 'name' attributes are (case-sensitive)
identical. Dimensions of the same typecan be algebraically combined using the 'power' attributes.
Normally dimensions will be aggregated and cancelled algebraically, but the 'preserve'
attribute can be used to prevent this. Thus a velocity gradient over length can be
defined as:<h:pre><unitType id="a1" preserve="true" xmlns=""><dimension name="length" power="1"/><dimension name="time" power="-1"/><dimension name="length" power="-1"/></unitType></h:pre>whereas cancelling the dimensions would give:<h:pre><unitType id="a1" preserve="true" xmlns=""><dimension name="time" power="-1"/></unitType></h:pre></h:div><h:div class="example" href="dimension1.xml"/><h:div class="example" href="dimension2.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence/><xsd:attributeGroup ref="dimensionBasis"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="power"/><xsd:attributeGroup ref="preserve"/></xsd:complexType></xsd:element>
Element unit
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A scientific unit.</h:div><h:div class="description"><h:p>A scientific unit. Units are of the following types:</h:p><h:ul><h: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. 2005-122-17 - this may be obsolete; PMR</h:li><h:li>nonSI Units. These will normally have a parent SI unit
(e.g. calorie has joule as an SI parent).</h:li><h:li>Constructed units. These use a syntax of the form:<h:pre><unit id="g.s-1" name="gram per second"
unitType="myUnitType:massPerTime">
<unit units="units:g" power="1"/>
<unit units="siUnits:s" power="-1"/>
</unit></h:pre>This defines a new unit (g.s-1) which is composed from two
existing units (units:g and siUnits:s) to create a new unit. The
conversion to SI is computed from the two child units and may be
added as a 'multiplierToSI' attribute. Only siUnits or units with
'multiplierToSI' can be used as child units; 'constantToSI cannot
be used yet. If the new unit points to a unitType then the dimension
can be checked. Thus if the published dimension of massPerTime does not
agree with mass.length-1 an error is throwable.
Alternatively a new unitType can be added as a child.</h:li></h:ul><h:p>The relationship of a unit to its SI parent is potentially complex and
inconsistencies may arise. The following are available:<h:ul><h:li>parentSI. This points to the ID of a parent SI unit. If this ID is the
same as the current unit the implication is that this is an SI unit.</h:li><h:li>isSI. a boolean indicating whether the current unit is SI.</h:li><h:li>multiplierToSI and constantToSI. If these are 1.0 and 0.0 (or missing)
the implication is that this unit is SI. However this is fragile as units can
be defined without these attributes and a unit could coincidentally have
no numeric differences but not be an SI unit.</h:li></h:ul></h:p></h:div><h:div class="example" href="unit1.xml"/><h:div class="curation">2003:04-09 Description or parentSI attribute enhanced.</h:div><h:div class="curation">2006:03-21 Added metadata and metadataList to content.</h:div>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">indicates whether a unit is an SI or derived SI unit.</h:div><h:div class="description">required on SI unit elements with value 'true'.
Optional on other units with attribute 'false'. A unitList should contain either
SI units or non-SI units but not both.</h:div>
<h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
<h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="unit" id="el.unit"><xsd:annotation><xsd:documentation><h:div class="summary">A scientific unit.</h:div><h:div class="description"><h:p>A scientific unit. Units are of the following types:</h:p><h:ul><h: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. 2005-122-17 - this may be obsolete; PMR</h:li><h:li>nonSI Units. These will normally have a parent SI unit
(e.g. calorie has joule as an SI parent).</h:li><h:li>Constructed units. These use a syntax of the form:<h:pre><unit id="g.s-1" name="gram per second"
unitType="myUnitType:massPerTime">
<unit units="units:g" power="1"/>
<unit units="siUnits:s" power="-1"/>
</unit></h:pre>This defines a new unit (g.s-1) which is composed from two
existing units (units:g and siUnits:s) to create a new unit. The
conversion to SI is computed from the two child units and may be
added as a 'multiplierToSI' attribute. Only siUnits or units with
'multiplierToSI' can be used as child units; 'constantToSI cannot
be used yet. If the new unit points to a unitType then the dimension
can be checked. Thus if the published dimension of massPerTime does not
agree with mass.length-1 an error is throwable.
Alternatively a new unitType can be added as a child.</h:li></h:ul><h:p>The relationship of a unit to its SI parent is potentially complex and
inconsistencies may arise. The following are available:<h:ul><h:li>parentSI. This points to the ID of a parent SI unit. If this ID is the
same as the current unit the implication is that this is an SI unit.</h:li><h:li>isSI. a boolean indicating whether the current unit is SI.</h:li><h:li>multiplierToSI and constantToSI. If these are 1.0 and 0.0 (or missing)
the implication is that this unit is SI. However this is fragile as units can
be defined without these attributes and a unit could coincidentally have
no numeric differences but not be an SI unit.</h:li></h:ul></h:p></h:div><h:div class="example" href="unit1.xml"/><h:div class="curation">2003:04-09 Description or parentSI attribute enhanced.</h:div><h:div class="curation">2006:03-21 Added metadata and metadataList to content.</h:div></xsd:documentation><xsd:appinfo><!-- this will constrain link integrity to parents, etc. --></xsd:appinfo></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadata"/><xsd:element ref="metadataList"/><xsd:element ref="description"/><xsd:element ref="annotation"/><xsd:element ref="definition" minOccurs="0" maxOccurs="1"/><xsd:element ref="unit" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="summary">Child unit used to build new unit.</h:div><h:div class="description"><h:p>These children must have 'units' and 'power' attributes.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="unitType" minOccurs="0" maxOccurs="1"><xsd:annotation><xsd:documentation><h:div class="summary">Child unitType describing type of new unit.</h:div><h:div class="description"><h:p>This can be added by the author (in which case they are
responsible for checking consistency) or calculated by the software
from the child units.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="units"><xsd:annotation><xsd:documentation><h:div class="summary">Reference to a unit.</h:div><h:div class="description"><h:p>This is used for the identification of child units when
new units are composed from existing ones. Athough the syntax looks
unusual it takes advantage of the tools for resolving units. See above for
syntax.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="abbreviation"><xsd:annotation><xsd:documentation><h:div class="summary">Abbreviation for the unit.</h:div><h:div class="description"><h:p>This may be obsolete and symbol should be preferred.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="symbol"><xsd:annotation><xsd:documentation><h:div class="summary">Symbol for the unit.</h:div><h:div class="description"><h:p>This may be used for typographical display but NOT for identification
as there is considerable variation in use.</h:p></h:div><h:div class="curation">2006-01-29: PMR. Added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="parentSI"/><xsd:attributeGroup ref="isSI"/><xsd:attributeGroup ref="unitType"/><xsd:attributeGroup ref="multiplierToData"/><xsd:attributeGroup ref="multiplierToSI"/><xsd:attributeGroup ref="constantToSI"/><xsd:attributeGroup ref="power"><xsd:annotation><xsd:documentation><h:div class="summary">Power of unit used to create new one.</h:div><h:div class="description"><h:p>Only allowed on child units</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element entry
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A dictionary entry.</h:div><h:div class="desacription">The original design for validation with attribute-based constraints is ponderous and fragile. In future constraints will be added through<h:tt>appinfo</h:tt>in<h:tt>annotation</h:tt>. We shall develop this further in the near future.</h:div><h:div class="curation">2003-03-30: added metadataList to content mode.</h:div><h:div class="example" href="entry1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">Number of digits after the point.</h:div><h:div class="description">This is used in dictionaries to define precision. However it might be replaced by xsd:facet.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A term in a dictionary.</h:div><h:div class="description">The term should be a noun or nounal phrase, with a separate definition and further description.</h:div>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">Whitespace.</h:div><h:div class="description">Attached to entry. This may be obsolete.</h:div>
Source
<xsd:element name="entry" id="el.entry"><xsd:annotation><xsd:documentation><h:div class="summary">A dictionary entry.</h:div><h:div class="desacription">The original design for validation with attribute-based constraints is ponderous and fragile. In future constraints will be added through<h:tt>appinfo</h:tt>in<h:tt>annotation</h:tt>. We shall develop this further in the near future.</h:div><h:div class="curation">2003-03-30: added metadataList to content mode.</h:div><h:div class="example" href="entry1.xml"/><!--
<h:div class="example" href="entry2.xml"></h:div>
--></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadataList"/><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="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="rows"/><xsd:attributeGroup ref="columns"/><xsd:attributeGroup ref="unitType"/><xsd:attributeGroup ref="minExclusive"/><xsd:attributeGroup ref="minInclusive"/><xsd:attributeGroup ref="maxExclusive"/><xsd:attributeGroup ref="maxInclusive"/><xsd:attributeGroup ref="totalDigits"/><xsd:attributeGroup ref="fractionDigits"/><xsd:attributeGroup ref="length"/><xsd:attributeGroup ref="minLength"/><xsd:attributeGroup ref="maxLength"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="whiteSpace"/><xsd:attributeGroup ref="pattern"/><xsd:attributeGroup ref="term"/></xsd:complexType></xsd:element>
Element enumeration
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An enumeration of value.</h:div><h:div class="description">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.</h:div><h:div class="example" href="enumeration1.xml"/>
<h:div class="summary">default value in an enumeration.</h:div><h:div class="description">A non-whitespace string (value is irrelevant) indicates that the content of this enumeration is the default value (usually of a scalar). It is an error to have more than one default. If the scalar in an instance document has no value (i.e. is empty or contains only whitespace) its value is given by the default. If the scalar in the instance is empty and no enumerations have a default attribute, an application may throw an error.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
Source
<xsd:element name="enumeration" id="el.enumeration"><xsd:annotation><xsd:documentation><h:div class="summary">An enumeration of value.</h:div><h:div class="description">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.</h:div><h:div class="example" href="enumeration1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="annotation" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="value"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="default"/></xsd:complexType></xsd:element>
Element relatedEntry
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An entry related in some way to a dictionary entry.</h:div><h:div class="description">The range of relationships is not restricted but should include parents, aggregation, seeAlso and so on. DataCategories from ISO12620 can be referenced through the namespaced mechanism.</h:div><h:div class="example" href="relatedEntry1.xml"/>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div>
Source
<xsd:element name="relatedEntry" id="el.relatedEntry"><xsd:annotation><xsd:documentation><h:div class="summary">An entry related in some way to a dictionary entry.</h:div><h:div class="description">The range of relationships is not restricted but should include parents, aggregation, seeAlso and so on. DataCategories from ISO12620 can be referenced through the namespaced mechanism.</h:div><h:div class="example" href="relatedEntry1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:attributeGroup ref="relatedEntryType"/><xsd:attributeGroup ref="href"><xsd:annotation><xsd:documentation><h:div class="specific">The related entry.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element eigen
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An element to hold eigenstuff.</h:div><h:div class="description">Holds an array of eigenvalues and a matrix of eigenvectors.</h:div><h:div class="example" href="eigen1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The orientation of the eigenvector matrix.</h:div><h:div class="description">Describes whether the vectors are columns or
rows. No default, so effectively mandatory unless you want to make implementers
guess and break applications.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="eigen" id="el.eigen"><xsd:annotation><xsd:documentation><h:div class="summary">An element to hold eigenstuff.</h:div><h:div class="description">Holds an array of eigenvalues and a matrix of eigenvectors.</h:div><h:div class="example" href="eigen1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="array" minOccurs="0"/><xsd:element ref="matrix" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="type"><xsd:annotation><xsd:documentation><h:div class="summary">No current semantics.</h:div><h:div class="description">Suggest it is developed
for the chemical/physical role, e.g. "molecular obitals", "inertial
matrix", "vibrational modes", "phonons", etc.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="eigenOrientation"/></xsd:complexType></xsd:element>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">A container for a fragment</h:div><h:div class="description"><h:p><h:tt>fragment</h:tt>is a container for a molecule, potentially to be joined
to other fragments. In addition there may be fragmentLists which represent branches
from the molecule. There may also be a join child which is normally only found
if there is a @countExpression.</h:p></h:div><h:div class="example" href="fragment1.xml"/><h:div class="curation">2006-11-23: created</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">General formula for the repeat count of the element.</h:div><h:div class="description">Experimental.
No fixed semantics or default.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="fragment" id="el.fragment"><xsd:annotation><xsd:documentation><h:div class="summary">A container for a fragment</h:div><h:div class="description"><h:p><h:tt>fragment</h:tt>is a container for a molecule, potentially to be joined
to other fragments. In addition there may be fragmentLists which represent branches
from the molecule. There may also be a join child which is normally only found
if there is a @countExpression.</h:p></h:div><h:div class="example" href="fragment1.xml"/><h:div class="curation">2006-11-23: created</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div class="summary">fragment normally contains molecules</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadataList"/><xsd:element ref="label"/><xsd:element ref="molecule"/><xsd:element ref="fragmentList"><xsd:annotation><xsd:documentation><h:div class="summary">branches from the moelcule.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="join"><xsd:annotation><xsd:documentation><h:div class="summary">the inter-fragment join.</h:div><h:div class="description">Normally it only makes sense with @countExpression.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>No formal semantics (yet).</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="countExpression"/></xsd:complexType></xsd:element>
Element fragmentList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more fragments and joins.</h:div><h:div class="description"><h:p><h:tt>fragmentList</h:tt>can contain several fragments and joins.
The normal content model is<h:pre>join fragment join fragment...</h:pre></h:p></h:div><h:div class="example" href="fragmentList1.xml"/><h:div class="curation">2006-07-20: PMR Added</h:div><h:div class="curation">2007-01-03: PMR Added role attribute</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="fragmentList" id="el.fragmentList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more fragments and joins.</h:div><h:div class="description"><h:p><h:tt>fragmentList</h:tt>can contain several fragments and joins.
The normal content model is<h:pre>join fragment join fragment...</h:pre></h:p></h:div><h:div class="example" href="fragmentList1.xml"/><h:div class="curation">2006-07-20: PMR Added</h:div><h:div class="curation">2007-01-03: PMR Added role attribute</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation></xsd:documentation></xsd:annotation><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadataList"/><xsd:element ref="join"/><xsd:element ref="label"/><xsd:element ref="fragment"/></xsd:choice><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">A specific isotope.</h:div><h:div class="description">Defines an isotope in terms of exact mass and spin. Differentiate from isotopeList which defines a mixture of isotope.</h:div><h:div class="example" href="isotope1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">The spin of a system.</h:div><h:div class="description">Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope.</h:div><h:div class="example" href="spin1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="isotope" id="el.isotope"><xsd:annotation><xsd:documentation><h:div class="summary">A specific isotope.</h:div><h:div class="description">Defines an isotope in terms of exact mass and spin. Differentiate from isotopeList which defines a mixture of isotope.</h:div><h:div class="example" href="isotope1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="abundance" minOccurs="0" maxOccurs="1"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="number"/><xsd:attributeGroup ref="spin"/><xsd:attributeGroup ref="elementType"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element isotopeList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more isotopes.</h:div><h:div class="description">Can contain several isotopes. These may be related in several ways. This allows the definition of natural abundance and averged enrichment.</h:div><h:div class="example" href="isotopeList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="isotopeList" id="el.isotopeList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more isotopes.</h:div><h:div class="description">Can contain several isotopes. These may be related in several ways. This allows the definition of natural abundance and averged enrichment.</h:div><h:div class="example" href="isotopeList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="isotope" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div>
<h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A lattice of dimension 3 or less.</h:div><h:div class="description">Lattice is a general approach to describing periodic systems.
It can have variable dimensionality or periodicity, and could be finite.</h:div><h:div class="note">_lattice_ is more general than _crystal_ in cmlCore which is used primarily for reporting
crystallographic experiments.`A lattice can be described by latticeVectors, cell axes
and angles, or metric tensors, etc. (only axes/angles are allowed under<h:tt>crystal</h:tt>). The dimensionality is enforced through a _system_ parent element.</h:div><h:div class="example" href="lattice3.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The primitivity of a lattice.</h:div><h:div class="description">No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency between spacegroups, symmetry operators, etc.</h:div>
<h:div class="summary">The spaceType of the lattice.</h:div><h:div class="description">Usually real or reciprocal. No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency for unitTypes, etc.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="lattice" id="el.lattice"><xsd:annotation><xsd:documentation><h:div class="summary">A lattice of dimension 3 or less.</h:div><h:div class="description">Lattice is a general approach to describing periodic systems.
It can have variable dimensionality or periodicity, and could be finite.</h:div><h:div class="note">_lattice_ is more general than _crystal_ in cmlCore which is used primarily for reporting
crystallographic experiments.`A lattice can be described by latticeVectors, cell axes
and angles, or metric tensors, etc. (only axes/angles are allowed under<h:tt>crystal</h:tt>). The dimensionality is enforced through a _system_ parent element.</h:div><h:div class="example" href="lattice3.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice><xsd:element ref="scalar" minOccurs="3" maxOccurs="6"><xsd:annotation><xsd:documentation><h:div class="summary">All appropriate cell parameters must be given, even
where angles are fixed by symmetry. The order is fixed as a,b,c,alpha,beta,gamma
and software can neglect any title or dictRef attributes. Error estimates
can be given if required. Any units can be used, but the defaults are
Angstrom (10^-10 m) and degrees. To be developed for lower dimensionality.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="latticeVector" minOccurs="1" maxOccurs="3"><!--
<h:div class="summary">A number of lattice vectors equal to the dimensionality. Note that some vectors may give rise to periodicty while others do not. Thus a surface can be described by two vector in the plane of the surface and one perpendicular to them.</h:div>
--></xsd:element><xsd:element ref="matrix" minOccurs="1" maxOccurs="1"><!--
<h:div class="summary">The metric tensor (normally for 3 dimensions).</h:div>
--></xsd:element></xsd:choice><xsd:element ref="symmetry" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="latticeType"/><xsd:attributeGroup ref="spaceType"/></xsd:complexType></xsd:element>
Element latticeVector
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A vector3 representing a lattice axis.</h:div><h:div class="description">a<h:tt>lattice</h:tt>can be represented by 1-3 non-linearly
dependent latticeVectors. If the dimensionality is less than 3 latticeVectors are the
preferred method. Similarly, if the axes show a mixture of periodicity and non-periodicity
latticeVectors can support this. The number of periodic vectors must correspond with
the periodicity attribute on a<h:tt>system</h:tt>element.<h:p>The vector must not be zero and units must be given. (Zero vectors must not be
used to reduce dimensionality).</h:p><h:p>A lattice vector defaults to periodic.</h:p>.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example
could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe
the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or
2D layer. The third vector is orthogonal and represents coordinates normal to the surface.
In this case only the direction, not the magnitude of the vector is important.</h:div><h:div class="example" href="latticeVector1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Is the axis periodic.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or 2D layer. The third vector is orthogonal and represents coordinates normal to the surface. In this case only the direction, not the magnitude of the vector is important.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="latticeVector" id="el.latticeVector"><xsd:annotation><xsd:documentation><h:div class="summary">A vector3 representing a lattice axis.</h:div><h:div class="description">a<h:tt>lattice</h:tt>can be represented by 1-3 non-linearly
dependent latticeVectors. If the dimensionality is less than 3 latticeVectors are the
preferred method. Similarly, if the axes show a mixture of periodicity and non-periodicity
latticeVectors can support this. The number of periodic vectors must correspond with
the periodicity attribute on a<h:tt>system</h:tt>element.<h:p>The vector must not be zero and units must be given. (Zero vectors must not be
used to reduce dimensionality).</h:p><h:p>A lattice vector defaults to periodic.</h:p>.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example
could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe
the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or
2D layer. The third vector is orthogonal and represents coordinates normal to the surface.
In this case only the direction, not the magnitude of the vector is important.</h:div><h:div class="example" href="latticeVector1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="vector3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="periodic"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element line3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A line in 3-space.</h:div><h:div class="description">A line characterised by one or two endpoints.</h:div><h:div class="curation">2006-01-02: the 6-number content has caused much confusion and
will be obsoleted in favour of the point3 and vector3 attributes</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A point in 3 dimensions.</h:div><h:div class="description">can be used for any complex
geometrical object, such as line.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">A vector in 3 dimensions.</h:div><h:div class="description">can be used for any complex geometrical object,
such as line.</h:div>
Source
<xsd:element name="line3" id="el.line3"><xsd:annotation><xsd:documentation><h:div class="summary">A line in 3-space.</h:div><h:div class="description">A line characterised by one or two endpoints.</h:div><h:div class="curation">2006-01-02: the 6-number content has caused much confusion and
will be obsoleted in favour of the point3 and vector3 attributes</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="line3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="point3"/><xsd:attributeGroup ref="vector3"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element link
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An internal or external link to other objects.</h:div><h:div class="description"><h:p><h:b>Semantics are similar to XLink, but simpler and only a subset is implemented.</h:b>This is intended to make the instances easy to create and read, and software
relatively easy to implement. The architecture is:</h:p><h:ul><h:li><h:b>A single element (<h:tt>link</h:tt>) used for all linking purposes.</h:b></h:li><h:li><h:b>The link types are determined by the<h:tt>type</h:tt>attribute and can be:</h:b>.<h:ul><h:li><h:b>locator</h:b>. This points to a single target and must carry either a<h:tt>ref</h:tt>or<h:tt>href</h:tt>attribute.<h:tt>locator</h:tt>links are usually children of an extended link.<h:li><h:b>arc</h:b>. This is a 1:1 link with both ends (<h:tt>from</h:tt>and<h:tt>to</h:tt>) defined.</h:li><h:li><h:b>extended</h: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).</h:li>Many-many links can be built up from arcs linking extended elements</h:li></h:ul><h:p>All links can have optional<h:tt>role</h:tt>attributes. The semantics of this are not defined;
you are encouraged to use a URI as described in the XLink specification.</h:p><h:p>There are two address spaces:</h:p><h:ul><h:li>The<h:tt>href</h:tt>attribute on locators behaves in the same way as<h:tt>href</h:tt>in
HTML and is of type<h:tt>xsd:anyURI</h:tt>. Its primary use is to use XPointer to reference
elements outside the document.</h:li><h:li>The<h:tt>ref</h:tt>attribute on locators and the<h:tt>from</h:tt>and<h:tt>to</h:tt>attributes on<h:tt>arc</h:tt>s refer to IDs (<h:em>without</h:em>the '#' syntax).</h:li></h:ul><h:p>Note: several other specific linking mechanisms are defined elsewhere in STM.<h:a href="el.relatedEntry">relatedEntry</h:a>should be used in dictionaries, and<h:a href="st.dictRef">dictRef</h:a>should be used to link to dictionaries. There are no required uses of<h:tt>link</h:tt>in STMML
but we have used it to map atoms, electrons and bonds in reactions in CML</h:p></h:li></h:ul><h:p><h:b>Relation to XLink</h: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:</h:p><h:ul><h:li><h:tt>type</h:tt>supports only<h:tt>extended</h:tt>,<h:tt>locator</h:tt>and<h:tt>arc</h:tt></h:li><h:li><h:tt>label</h:tt>is not supported and<h:tt>id</h:tt>s are used as targets of links.</h:li><h:li><h:tt>show</h:tt>and<h:tt>actuate</h:tt>are not supported.</h:li><h:li><h:tt>xlink:title</h:tt>is not supported (all STM elements can have a<h:tt>title</h:tt>attribute).</h:li><h:li><h:tt>xlink:role</h: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</h:li><h:li>The<h:tt>to</h:tt>and<h:tt>from</h:tt>attributes point to IDs rather than labels</h:li><h:li>The xlink namespace is not used</h:li><h: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</h:li></h:ul></h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The base of one or more links.</h:div><h:div class="description">On link elements the value is the single id of an element within the document or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">The target of one or more links.</h:div><h:div class="summary">On link elements the value is the single id of an element within the document or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:element name="link" id="el.link"><xsd:annotation><xsd:documentation><h:div class="summary">An internal or external link to other objects.</h:div><h:div class="description"><h:p><h:b>Semantics are similar to XLink, but simpler and only a subset is implemented.</h:b>This is intended to make the instances easy to create and read, and software
relatively easy to implement. The architecture is:</h:p><h:ul><h:li><h:b>A single element (<h:tt>link</h:tt>) used for all linking purposes.</h:b></h:li><h:li><h:b>The link types are determined by the<h:tt>type</h:tt>attribute and can be:</h:b>.<h:ul><h:li><h:b>locator</h:b>. This points to a single target and must carry either a<h:tt>ref</h:tt>or<h:tt>href</h:tt>attribute.<h:tt>locator</h:tt>links are usually children of an extended link.<h:li><h:b>arc</h:b>. This is a 1:1 link with both ends (<h:tt>from</h:tt>and<h:tt>to</h:tt>) defined.</h:li><h:li><h:b>extended</h: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).</h:li>Many-many links can be built up from arcs linking extended elements</h:li></h:ul><h:p>All links can have optional<h:tt>role</h:tt>attributes. The semantics of this are not defined;
you are encouraged to use a URI as described in the XLink specification.</h:p><h:p>There are two address spaces:</h:p><h:ul><h:li>The<h:tt>href</h:tt>attribute on locators behaves in the same way as<h:tt>href</h:tt>in
HTML and is of type<h:tt>xsd:anyURI</h:tt>. Its primary use is to use XPointer to reference
elements outside the document.</h:li><h:li>The<h:tt>ref</h:tt>attribute on locators and the<h:tt>from</h:tt>and<h:tt>to</h:tt>attributes on<h:tt>arc</h:tt>s refer to IDs (<h:em>without</h:em>the '#' syntax).</h:li></h:ul><h:p>Note: several other specific linking mechanisms are defined elsewhere in STM.<h:a href="el.relatedEntry">relatedEntry</h:a>should be used in dictionaries, and<h:a href="st.dictRef">dictRef</h:a>should be used to link to dictionaries. There are no required uses of<h:tt>link</h:tt>in STMML
but we have used it to map atoms, electrons and bonds in reactions in CML</h:p></h:li></h:ul><h:p><h:b>Relation to XLink</h: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:</h:p><h:ul><h:li><h:tt>type</h:tt>supports only<h:tt>extended</h:tt>,<h:tt>locator</h:tt>and<h:tt>arc</h:tt></h:li><h:li><h:tt>label</h:tt>is not supported and<h:tt>id</h:tt>s are used as targets of links.</h:li><h:li><h:tt>show</h:tt>and<h:tt>actuate</h:tt>are not supported.</h:li><h:li><h:tt>xlink:title</h:tt>is not supported (all STM elements can have a<h:tt>title</h:tt>attribute).</h:li><h:li><h:tt>xlink:role</h: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</h:li><h:li>The<h:tt>to</h:tt>and<h:tt>from</h:tt>attributes point to IDs rather than labels</h:li><h:li>The xlink namespace is not used</h:li><h: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</h:li></h:ul></h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="from"/><xsd:attributeGroup ref="to"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="fromType"><xsd:annotation><xsd:documentation><h:div class="specific">The type of the object/element in the 'from' attributes. Requires the objects referenced by the 'from' attributes to have a given elementType. Can be overridden by 'from' attributes in individual links. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="toType"><xsd:annotation><xsd:documentation><h:div class="specific">The type of the object/element in the 'to' attributes. Requires the objects referenced by the 'to' attributes to have a given elementType. Can be overridden by 'to' attributes in individual links. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="fromSet"><xsd:annotation><xsd:documentation><h:div class="specific">The set of ids in the base of the link. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="toSet"><xsd:annotation><xsd:documentation><h:div class="specific">The set of ids in the target of the link. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="fromContext"><xsd:annotation><xsd:documentation><h:div class="specific">The id of the ancestral element of objects referenced by 'from' attributes. Provides a context for uniquifying the references in the 'from' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'fromContext'. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="toContext"><xsd:annotation><xsd:documentation><h:div class="specific">The id of the ancestral element of objects referenced by 'to' attributes. Provides a context for uniquifying the references in the 'to' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'toContext'. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">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.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="href"><xsd:annotation><xsd:documentation><h:div class="specific">The target of the (locator) link, outside the document.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="linkType"/></xsd:complexType></xsd:element>
Element map
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for links</h:div><h:div class="description"><h:p>Usage is now standardized with map as the container and link as the individual links. The links are often effectively typed pointers to other parts of the document. The type can be set for all links by the 'fromType' and 'toType' attributes, either in the map, which then applied to all links by default, or in individual links, when it overrides the map setting. Since ids may not be unique within a document the refs can be given context with the 'fromRef' and 'toRef' attributes in the map element. If more than one context is used it may be better to use multiple maps. The role of map, and its relationship to RDF is still being developed.</h:p><h:p>Currently (2005) map has primarily been used to map atoms between reactants and products, but we also expect shortly to extend it to peak assignments and several otherr areas. A map consists of a number of links, which can be directional, relating two elements through their ids. Reference is through the mandatory 'to' and 'from' attributes which must point to existing id attributes on elements. The type of the dereferenced element can be specified in 'toType' and 'fromType' which, while redundant, is an aid to software and acts as a check on referential type integrity.</h:p><h:p>In principle any element can be linked to any other, with 1:1, 1:n, and n:m topology. We expect maps to be used for precise chemical concepts such as reactions, peak assignments, electron management, molecular superpositions, etc. and that these are supported by bespoke code. For other links, especially with complex topology, users should consider whether RDF may be more appropriate.</h:p><h:p>In some cases partial mapping is known (e.g. one set of atoms maps to another set), but the precise links are unknown. (This is not the same as n:m mapping where n*m precise links would be expected). In some cases there may be objects such as atomSets or peakGroups which could be linked to support this. Alternatively the 'fromSet' and 'toSet' attributes can be used to hold a list of ids. Thus from='a1 a2' to='b3 b4' might imply that there were two precise links (either {a1=>b3, a2=>b4} or {a1=>b4, a2=>b3}). This is most likely to be used in intermediate documents where more precise semantics can be added later. The ids must all refer to elements of the same type. Note that a 'to' link referencing a single atomSet (toType='atomSet') is not the same as a 'toSet' of toType='atom' with multiple atomIds. The first would require an 'atomSet' element in the document; the second would not. The precise semantics such as the order of ids are application-dependent. If the order is known in both the toSet and fromSet then individual links should be used rather than adding the burden of deconstruction on the implementer.</h:p></h:div><h:div class="curation">2005-06-18: added typing and role and updated docs.</h:div><h:div class="curation">2006-08-05: added ref attribute.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:element name="map" id="el.map"><xsd:annotation><xsd:documentation><h:div class="summary">A container for links</h:div><h:div class="description"><h:p>Usage is now standardized with map as the container and link as the individual links. The links are often effectively typed pointers to other parts of the document. The type can be set for all links by the 'fromType' and 'toType' attributes, either in the map, which then applied to all links by default, or in individual links, when it overrides the map setting. Since ids may not be unique within a document the refs can be given context with the 'fromRef' and 'toRef' attributes in the map element. If more than one context is used it may be better to use multiple maps. The role of map, and its relationship to RDF is still being developed.</h:p><h:p>Currently (2005) map has primarily been used to map atoms between reactants and products, but we also expect shortly to extend it to peak assignments and several otherr areas. A map consists of a number of links, which can be directional, relating two elements through their ids. Reference is through the mandatory 'to' and 'from' attributes which must point to existing id attributes on elements. The type of the dereferenced element can be specified in 'toType' and 'fromType' which, while redundant, is an aid to software and acts as a check on referential type integrity.</h:p><h:p>In principle any element can be linked to any other, with 1:1, 1:n, and n:m topology. We expect maps to be used for precise chemical concepts such as reactions, peak assignments, electron management, molecular superpositions, etc. and that these are supported by bespoke code. For other links, especially with complex topology, users should consider whether RDF may be more appropriate.</h:p><h:p>In some cases partial mapping is known (e.g. one set of atoms maps to another set), but the precise links are unknown. (This is not the same as n:m mapping where n*m precise links would be expected). In some cases there may be objects such as atomSets or peakGroups which could be linked to support this. Alternatively the 'fromSet' and 'toSet' attributes can be used to hold a list of ids. Thus from='a1 a2' to='b3 b4' might imply that there were two precise links (either {a1=>b3, a2=>b4} or {a1=>b4, a2=>b3}). This is most likely to be used in intermediate documents where more precise semantics can be added later. The ids must all refer to elements of the same type. Note that a 'to' link referencing a single atomSet (toType='atomSet') is not the same as a 'toSet' of toType='atom' with multiple atomIds. The first would require an 'atomSet' element in the document; the second would not. The precise semantics such as the order of ids are application-dependent. If the order is known in both the toSet and fromSet then individual links should be used rather than adding the burden of deconstruction on the implementer.</h:p></h:div><h:div class="curation">2005-06-18: added typing and role and updated docs.</h:div><h:div class="curation">2006-08-05: added ref attribute.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:element ref="link"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="fromType"><xsd:annotation><xsd:documentation><h:div class="specific">The type of the object/element in the 'from' attributes. Requires the objects referenced by the 'from' attributes to have a given elementType. Can be overridden by 'from' attributes in individual links. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="toType"><xsd:annotation><xsd:documentation><h:div class="specific">The type of the object/element in the 'to' attributes. Requires the objects referenced by the 'to' attributes to have a given elementType. Can be overridden by 'to' attributes in individual links. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="fromContext"><xsd:annotation><xsd:documentation><h:div class="specific">The id of the ancestral element of objects referenced by 'from' attributes. Provides a context for uniquifying the references in the 'from' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'fromContext'. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="toContext"><xsd:annotation><xsd:documentation><h:div class="specific">The id of the ancestral element of objects referenced by 'to' attributes. Provides a context for uniquifying the references in the 'to' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'toContext'. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">The role of the map. Semantics are undefined, and can be used to provide a small semi-controlled vocabulary for identifying maps of different types. 2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element mechanism
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The mechanism of a reaction.</h:div><h:div class="description"><h:p>In some cases this may be a simple textual description or reference within a controlled vocabulary. In others it may describe the complete progress of the reaction, including topological or cartesian movement of atoms, bonds and electrons and annotation with varying quantities (e.g. energies).</h:p><h:p>For named reaction mechanisms ("Diels-Alder", "ping-pong", "Claisen rearrangement", etc.) the<h:tt>name</h:tt>element should be used. For classification (e.g. "hydrolysis"), the<h:tt>label</h:tt>may be more appropriate.</h:p><h:p>In more detailed cases the mechanism refers to components of the<h:tt>reaction</h:tt>element. Thus bond23 might be cleaved while bond19 is transformed (mapped) to bond99. The<h:tt>mechanismComponent</h:tt>can be used to refer to components and add annotation. This is still experimental.</h:p></h:div><h:div class="description"><h:p>IUPAC Compendium of Chemical Terminology 2nd Edition (1997) describes a mechanism as:<h:blockquote>A detailed description of the process leading from the reactants to the
products of a reaction, including a characterization as complete as possible
of the composition, structure, energy and other properties of reaction
intermediates, products and transition states. An acceptable mechanism of
a specified reaction (and there may be a number of such alternative mechanisms
not excluded by the evidence) must be consistent with the reaction
stoichiometry, the rate law and with all other available experimental data,
such as the stereochemical course of the reaction. Inferences concerning
the electronic motions which dynamically interconvert successive species
along the reaction path (as represented by curved arrows, for example) are
often included in the description of a mechanism.
It should be noted that for many reactions all this information is not
available and the suggested mechanism is based on incomplete experimental
data. It is not appropriate to use the term mechanism to describe a
statement of the probable sequence in a set of stepwise reactions. That
should be referred to as a reaction sequence, and not a mechanism.</h:blockquote></h:p><h:p>CMLReact provides reactionScheme and annotions to describe the reaction sequence and both it and<h:tt>mechanism</h:tt>could co-occur within a reactionScheme container.</h:p></h:div><h:div class="curation">2006-02-28 PMR: changed content model to choice.</h:div><h:div class="example" href="mechanism1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="mechanism" id="el.mechanism"><xsd:annotation><xsd:documentation><h:div class="summary">The mechanism of a reaction.</h:div><h:div class="description"><h:p>In some cases this may be a simple textual description or reference within a controlled vocabulary. In others it may describe the complete progress of the reaction, including topological or cartesian movement of atoms, bonds and electrons and annotation with varying quantities (e.g. energies).</h:p><h:p>For named reaction mechanisms ("Diels-Alder", "ping-pong", "Claisen rearrangement", etc.) the<h:tt>name</h:tt>element should be used. For classification (e.g. "hydrolysis"), the<h:tt>label</h:tt>may be more appropriate.</h:p><h:p>In more detailed cases the mechanism refers to components of the<h:tt>reaction</h:tt>element. Thus bond23 might be cleaved while bond19 is transformed (mapped) to bond99. The<h:tt>mechanismComponent</h:tt>can be used to refer to components and add annotation. This is still experimental.</h:p></h:div><h:div class="description"><h:p>IUPAC Compendium of Chemical Terminology 2nd Edition (1997) describes a mechanism as:<h:blockquote>A detailed description of the process leading from the reactants to the
products of a reaction, including a characterization as complete as possible
of the composition, structure, energy and other properties of reaction
intermediates, products and transition states. An acceptable mechanism of
a specified reaction (and there may be a number of such alternative mechanisms
not excluded by the evidence) must be consistent with the reaction
stoichiometry, the rate law and with all other available experimental data,
such as the stereochemical course of the reaction. Inferences concerning
the electronic motions which dynamically interconvert successive species
along the reaction path (as represented by curved arrows, for example) are
often included in the description of a mechanism.
It should be noted that for many reactions all this information is not
available and the suggested mechanism is based on incomplete experimental
data. It is not appropriate to use the term mechanism to describe a
statement of the probable sequence in a set of stepwise reactions. That
should be referred to as a reaction sequence, and not a mechanism.</h:blockquote></h:p><h:p>CMLReact provides reactionScheme and annotions to describe the reaction sequence and both it and<h:tt>mechanism</h:tt>could co-occur within a reactionScheme container.</h:p></h:div><h:div class="curation">2006-02-28 PMR: changed content model to choice.</h:div><h:div class="example" href="mechanism1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="name"/><xsd:element ref="label"/><xsd:element ref="description"/><xsd:element ref="mechanismComponent"/></xsd:choice><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element mechanismComponent
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An information component within a reaction mechanism.</h:div><h:div class="description"><h:p>Information components can represent both physical constituents of the reaction or abstract concepts (types of bond cleavage, thermodynamics, etc.). There are several ways that components of the reaction can be annotated and/or quantified. One approach will be to refer to specific bonds and atoms through their ids and use mechanismComponent to describe their role, properties, etc. Another is to use mechanismComponent to identify types of bond formed/broken without reference to actual atoms and bonds (initially through the<h:tt>name</h:tt>element). Yet another will be to include information on the reaction profile.</h:p><h:p>This is still experimental.</h:p></h:div><h:div class="example" href="mechanismComponent1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="mechanismComponent" id="el.mechanismComponent"><xsd:annotation><xsd:documentation><h:div class="summary">An information component within a reaction mechanism.</h:div><h:div class="description"><h:p>Information components can represent both physical constituents of the reaction or abstract concepts (types of bond cleavage, thermodynamics, etc.). There are several ways that components of the reaction can be annotated and/or quantified. One approach will be to refer to specific bonds and atoms through their ids and use mechanismComponent to describe their role, properties, etc. Another is to use mechanismComponent to identify types of bond formed/broken without reference to actual atoms and bonds (initially through the<h:tt>name</h:tt>element). Yet another will be to include information on the reaction profile.</h:p><h:p>This is still experimental.</h:p></h:div><h:div class="example" href="mechanismComponent1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element module
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A module in a calculation.</h:div><h:div class="description"><h:p>Many programs are based on discrete modules which produce chunks of output. There are also conceptual chunks such as initialisation, calculation and summary/final which often have finer submodules such as cycle, iteration, snapshot, etc. There is no controlled vocabulary but a typical structure is shown in the example. One of the challenges of CCML is to find communality between different programs and to use agreed abstractions for the modules.</h:p></h:div><h:div class="example" href="module1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">Serial number or other id.</h:div><h:div class="summary">Currently only on module. Modules with the same _role_ attribute can be distinguished by _serial_. This is often an integer but other schemes may be used.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="module" id="el.module"><xsd:annotation><xsd:documentation><h:div class="summary">A module in a calculation.</h:div><h:div class="description"><h:p>Many programs are based on discrete modules which produce chunks of output. There are also conceptual chunks such as initialisation, calculation and summary/final which often have finer submodules such as cycle, iteration, snapshot, etc. There is no controlled vocabulary but a typical structure is shown in the example. One of the challenges of CCML is to find communality between different programs and to use agreed abstractions for the modules.</h:p></h:div><h:div class="example" href="module1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="serial"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">The module can have a program-specific name through its title or dictRef (e.g. "MINIM", "l201") and a generic role ("dynamicsCalculation", "equilibration", etc.). In general role will be controlled by CCML.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element moleculeList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more molecules.</h:div><h:div class="description"><h:p><h:tt>moleculeList</h:tt>can contain several molecules.
These may be related in many ways and there is are controlled
semantics. However it should not be used for a molecule
consisting of descendant molecules for which molecule
should be used.
A moleculeList can contain nested moleculeLists.</h:p></h:div><h:div class="example" href="moleculeList1.xml"/><h:div class="curation">2006-07-20: PMR Added</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="moleculeList" id="el.moleculeList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more molecules.</h:div><h:div class="description"><h:p><h:tt>moleculeList</h:tt>can contain several molecules.
These may be related in many ways and there is are controlled
semantics. However it should not be used for a molecule
consisting of descendant molecules for which molecule
should be used.
A moleculeList can contain nested moleculeLists.</h:p></h:div><h:div class="example" href="moleculeList1.xml"/><h:div class="curation">2006-07-20: PMR Added</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div><h:tt>metadataList</h:tt>contains<h:tt>metadata</h:tt>.<h:tt>list</h:tt>is for experimental and other data.<h:tt>moleculeList</h:tt>normally contains<h:tt>molecule</h:tt>s but we make provision for nested moleculeLists if required. The<h:tt>molecule</h:tt>s can be a set of reference molecules which occur in the<h:tt>molecule</h:tt>s and can be referenced. This makes the molecules more readable and normalizes data when molecules are used more than once.</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="list" minOccurs="0" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="moleculeList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="molecule" minOccurs="0" maxOccurs="unbounded"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element object
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An object which might occur in scientific data or narrative.</h:div><h:div class="description">Deliberately vague. Thus an instrument might be built from sub component objects, or a program could be composed of smaller modules (objects).<h:tt>object</h:tt>could be used to encapsulate graphical primitives (e.g. in reaction schemes, drawings of apparatus, etc.). Unrestricted content model.</h:div><h:div class="example" href="object1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="object" id="el.object"><xsd:annotation><xsd:documentation><h:div class="summary">An object which might occur in scientific data or narrative.</h:div><h:div class="description">Deliberately vague. Thus an instrument might be built from sub component objects, or a program could be composed of smaller modules (objects).<h:tt>object</h:tt>could be used to encapsulate graphical primitives (e.g. in reaction schemes, drawings of apparatus, etc.). Unrestricted content model.</h:div><h:div class="example" href="object1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="count"/></xsd:complexType></xsd:element>
Element parameterList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more parameters.</h:div><h:div class="description">parameterList can contain several parameters.</h:div><h:div class="example" href="parameterList1.xml"/><h:div class="curation">2006-02-16:PMR. Added parameterList as child</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="parameterList" id="el.parameterList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more parameters.</h:div><h:div class="description">parameterList can contain several parameters.</h:div><h:div class="example" href="parameterList1.xml"/><h:div class="curation">2006-02-16:PMR. Added parameterList as child</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="parameter"/><xsd:element ref="parameterList"/><!-- I don't know how to include this...
<xsd:any processContents="lax"/>
--></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/></xsd:complexType></xsd:element>
Element peak
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A peak; annotated by human or machine.</h:div><h:div class="description"><h:p>A<h:tt>peak</h:tt>can describe:<h:ul><h:li>A single point in a spectrum. Usually a maximum but could be a shoulder, inflexion or indeed any point of interest.</h:li><h:li>A continuous range of values within a spectrum, defined by maximum and minimum values on either/both axes</h:li></h:ul></h:p>The finer structure of the peak can be given with one or more peakStructure
children</h:div><h:div class="description">The units should always be given. (The raw spectral data may unfortunately use different units and no assumptions should be made).</h:div><h:div class="description">The content model includes atom, bond, molecule, but these
are deprecated and should be replaced by atomRefs, etc.</h:div><h:div class="curation">2005-11-22: PMR. Added moleculeRefs</h:div><h:div class="example" href="peak1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div>
<h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div>
<h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div>
<h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div>
<h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div>
<h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div>
<h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div>
<h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div>
<h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div>
<h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div>
<h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div>
<h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div>
<h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div>
Source
<xsd:element name="peak" id="el.peak"><xsd:annotation><xsd:documentation><h:div class="summary">A peak; annotated by human or machine.</h:div><h:div class="description"><h:p>A<h:tt>peak</h:tt>can describe:<h:ul><h:li>A single point in a spectrum. Usually a maximum but could be a shoulder, inflexion or indeed any point of interest.</h:li><h:li>A continuous range of values within a spectrum, defined by maximum and minimum values on either/both axes</h:li></h:ul></h:p>The finer structure of the peak can be given with one or more peakStructure
children</h:div><h:div class="description">The units should always be given. (The raw spectral data may unfortunately use different units and no assumptions should be made).</h:div><h:div class="description">The content model includes atom, bond, molecule, but these
are deprecated and should be replaced by atomRefs, etc.</h:div><h:div class="curation">2005-11-22: PMR. Added moleculeRefs</h:div><h:div class="example" href="peak1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0"><xsd:annotation><xsd:documentation><h:div class="summary">Allows<h:i>inter alia</h:i>the provenance of the peak assignment to be recorde.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="atom"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-9. DEPRECATED; use atomRefs</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="bond"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-9. DEPRECATED; use bondRefs</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="molecule"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-9. DEPRECATED; use moleculeRefs
when developed</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="peakStructure"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-9. PMR, added</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="peakHeight"/><xsd:attributeGroup ref="peakMultiplicity"/><xsd:attributeGroup ref="peakShape"/><xsd:attributeGroup ref="integral"/><xsd:attributeGroup ref="peakUnits"/><xsd:attributeGroup ref="xMin"/><xsd:attributeGroup ref="xMax"/><xsd:attributeGroup ref="xValue"/><xsd:attributeGroup ref="xWidth"/><xsd:attributeGroup ref="xUnits"/><xsd:attributeGroup ref="yMin"/><xsd:attributeGroup ref="yMax"/><xsd:attributeGroup ref="yValue"/><xsd:attributeGroup ref="yWidth"/><xsd:attributeGroup ref="yUnits"/><xsd:attributeGroup ref="atomRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Atoms contributing to this peak</h:div><h:div class="description">The primary set of atoms responsible for
the peak such as an NMR peak. Coupling constants and similar splitting
should not use this but peakStructure. At present there is no substructure to this
attribute or concept and only one attribute is allowed. It may be
combined with bondRefs. Even single atoms should use atomRefs, not atomRef.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="bondRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Bonds contributing to this peak</h:div><h:div class="description">The primary set of bonds responsible for
the peak such as an IR frequency. At present there is no substructure to this
attribute or concept and only one attribute is allowed. It may be
combined with atomRefs.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="moleculeRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Molecule(s) contributing to this peak</h:div><h:div class="description">The molecule or molecule responsible for
the peak. At present there is no substructure to this
attribute or concept and only one attribute is allowed. This might, for example,
be used to manage a mass spectrum or chromatogram</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element peakStructure
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The structure of a peak.</h:div><h:div class="description">Primarily to record couplings and other fine
structure. At present we have tested this on HNMR spectra, C13 NMR and
simple IR. We believe that other types of spectroscopy (ESR, NQR, etc) can be
represented to some extent, but there may be systems beyond the current
expressive power.</h:div><h:div>For molecules without symmetry we believe that most of the important
types of NMR coupling can be represented. Thus an atom which gives rise to
two couplings can have two child PeakStructures, and this is shown
in example1.<h:pre><cml xmlns="http://www.xml-cml.org/schema">
<!-- Ha ... Hb ... Hc1, Hc2 -->
<molecule id="m1">
<atomArray>
<atom id="a1" elementType="H">
<label value="Ha"/>
</atom>
<atom id="a2" elementType="H">
<label value="Hb"/>
</atom>
<atom id="a3" elementType="H">
<label value="Hc1"/>
</atom>
<atom id="a4" elementType="H">
<label value="Hc2"/>
</atom>
</atomArray>
</molecule>
<spectrum id="spectrum2" title="test peaks">
<peakList>
<peak id="p1" title="Ha" atomRefs="a1"
peakShape="sharp" xUnits="unit:ppm" xValue="6.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="12" units="unit:hertz" atomRefs="a2"/>
</peak>
<peak id="p2" title="Hb" atomRefs="a2"
peakShape="sharp" xUnits="unit:ppm" xValue="7.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="12" units="unit:hertz" atomRefs="a1"/>
<peakStructure type="coupling" peakMultiplicity="triplet121"
value="15" units="unit:hertz" atomRefs="a3 a4"/>
</peak>
<peak id="p3" title="Hc" atomRefs="a3 a4"
peakShape="sharp" xUnits="unit:ppm" xValue="8.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="15" units="unit:hertz" atomRefs="a2"/>
</peak>
</peakList>
</spectrum>
</cml></h:pre>Where a peak is due to symmetry-related atoms there are
different couplings to symmetrical atoms. Thus in an AA'BB' system there
can be two couplings to the A atoms and we need nested peakStructures to
represent these. In this case the order of the atoms in the peak@atomRefs
maps to the order of the grandchildren. See example2.<h:pre><!-- AA'BB' where there are 2 Ha and 2 Hb with two couplings
J1 Ha ... Hb and Ha' ... Hb'
J2 Ha ... Hb' and Ha' ... Hb
-->
<molecule id="m1">
<atomArray>
<atom id="a1" elementType="H">
<label value="Ha"/>
</atom>
<atom id="a2" elementType="H">
<label value="Ha'"/>
</atom>
<atom id="a3" elementType="H">
<label value="Hb"/>
</atom>
<atom id="a4" elementType="H">
<label value="Hb'"/>
</atom>
</atomArray>
</molecule>
<spectrum id="spectrum2" title="test peaks">
<peakList>
<!-- the ORDER of a1 and a2 is linked to the ORDER of the
grandchildren elements, i.e. a1 couples to atoms in ps11 and ps21
while a2 relates to atoms is ps21 and ps22
-->
<peak id="p1" title="Ha" atomRefs="a1, a2"
peakShape="sharp" xUnits="unit:ppm" xValue="6.0">
<peakStructure id="ps1" type="coupling" peakMultiplicity="doublet"
value="10" units="unit:hertz">
<peakStructure id="ps11" atomRefs="a3"/>
<peakStructure id="ps12" atomRefs="a4"/>
</peakStructure>
<peakStructure id="ps2" type="coupling" peakMultiplicity="doublet"
value="2" units="unit:hertz">
<peakStructure id="ps21" atomRefs="a4"/>
<peakStructure id="ps22" atomRefs="a3"/>
</peakStructure>
</peak>
</peakList>
</spectrum>
</cml></h:pre></h:div><h:div class="example" href="peakStructure1.xml"/><h:div class="example" href="peakStructure2.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
Source
<xsd:element name="peakStructure" id="el.peakStructure"><xsd:annotation><xsd:documentation><h:div class="summary">The structure of a peak.</h:div><h:div class="description">Primarily to record couplings and other fine
structure. At present we have tested this on HNMR spectra, C13 NMR and
simple IR. We believe that other types of spectroscopy (ESR, NQR, etc) can be
represented to some extent, but there may be systems beyond the current
expressive power.</h:div><h:div>For molecules without symmetry we believe that most of the important
types of NMR coupling can be represented. Thus an atom which gives rise to
two couplings can have two child PeakStructures, and this is shown
in example1.<h:pre><cml xmlns="http://www.xml-cml.org/schema">
<!-- Ha ... Hb ... Hc1, Hc2 -->
<molecule id="m1">
<atomArray>
<atom id="a1" elementType="H">
<label value="Ha"/>
</atom>
<atom id="a2" elementType="H">
<label value="Hb"/>
</atom>
<atom id="a3" elementType="H">
<label value="Hc1"/>
</atom>
<atom id="a4" elementType="H">
<label value="Hc2"/>
</atom>
</atomArray>
</molecule>
<spectrum id="spectrum2" title="test peaks">
<peakList>
<peak id="p1" title="Ha" atomRefs="a1"
peakShape="sharp" xUnits="unit:ppm" xValue="6.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="12" units="unit:hertz" atomRefs="a2"/>
</peak>
<peak id="p2" title="Hb" atomRefs="a2"
peakShape="sharp" xUnits="unit:ppm" xValue="7.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="12" units="unit:hertz" atomRefs="a1"/>
<peakStructure type="coupling" peakMultiplicity="triplet121"
value="15" units="unit:hertz" atomRefs="a3 a4"/>
</peak>
<peak id="p3" title="Hc" atomRefs="a3 a4"
peakShape="sharp" xUnits="unit:ppm" xValue="8.0">
<peakStructure type="coupling" peakMultiplicity="doublet11"
value="15" units="unit:hertz" atomRefs="a2"/>
</peak>
</peakList>
</spectrum>
</cml></h:pre>Where a peak is due to symmetry-related atoms there are
different couplings to symmetrical atoms. Thus in an AA'BB' system there
can be two couplings to the A atoms and we need nested peakStructures to
represent these. In this case the order of the atoms in the peak@atomRefs
maps to the order of the grandchildren. See example2.<h:pre><!-- AA'BB' where there are 2 Ha and 2 Hb with two couplings
J1 Ha ... Hb and Ha' ... Hb'
J2 Ha ... Hb' and Ha' ... Hb
-->
<molecule id="m1">
<atomArray>
<atom id="a1" elementType="H">
<label value="Ha"/>
</atom>
<atom id="a2" elementType="H">
<label value="Ha'"/>
</atom>
<atom id="a3" elementType="H">
<label value="Hb"/>
</atom>
<atom id="a4" elementType="H">
<label value="Hb'"/>
</atom>
</atomArray>
</molecule>
<spectrum id="spectrum2" title="test peaks">
<peakList>
<!-- the ORDER of a1 and a2 is linked to the ORDER of the
grandchildren elements, i.e. a1 couples to atoms in ps11 and ps21
while a2 relates to atoms is ps21 and ps22
-->
<peak id="p1" title="Ha" atomRefs="a1, a2"
peakShape="sharp" xUnits="unit:ppm" xValue="6.0">
<peakStructure id="ps1" type="coupling" peakMultiplicity="doublet"
value="10" units="unit:hertz">
<peakStructure id="ps11" atomRefs="a3"/>
<peakStructure id="ps12" atomRefs="a4"/>
</peakStructure>
<peakStructure id="ps2" type="coupling" peakMultiplicity="doublet"
value="2" units="unit:hertz">
<peakStructure id="ps21" atomRefs="a4"/>
<peakStructure id="ps22" atomRefs="a3"/>
</peakStructure>
</peak>
</peakList>
</spectrum>
</cml></h:pre></h:div><h:div class="example" href="peakStructure1.xml"/><h:div class="example" href="peakStructure2.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="summary">Allows<h:i>inter alia</h:i>the provenance of the peakStructure assignment to be recorded.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="peakStructure" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div class="summary">Allows identification of couplings in symmetric systems. May also
be usable for other complicated systems.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="peakMultiplicity"/><xsd:attributeGroup ref="peakStructureType"/><xsd:attributeGroup ref="peakShape"/><xsd:attributeGroup ref="value"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="atomRefs"><xsd:annotation><xsd:documentation><h:div class="summary">The atoms to which the peakStructure refers.</h:div><h:div class="description">Allows identification of the atoms to which the
peak is coupled (not the atoms contributing to the primnary reference for
which<tt xmlns="">peak</tt>should be used). It may be
combined with bondRefs. Even single atoms should use atomRefs, not atomRef.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="bondRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Bonds contributing to this peakStructure</h:div><h:div class="description">Even a single bond should use bondRefs, not bondRef</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element peakGroup
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A list of closely related peaks or peakGroups.</h:div><h:div class="description">Distinguish between<h:tt>peakList</h:tt>(primarily a navigational container) and<h:tt>peakGroup</h:tt>where the peaks (or groups) have some close relation not shared by all peaks. All descendants must use consistent units.</h:div><h:div class="curation">2005-11-22. added atomRefs, bondRefs and moleculeRefs and deprecated
atom, bond, molecule children</h:div><h:div class="example" href="peakGroup1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div>
<h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div>
<h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div>
<h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div>
<h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div>
<h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div>
<h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div>
<h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div>
<h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div>
<h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div>
<h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div>
<h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div>
<h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div>
Source
<xsd:element name="peakGroup" id="el.peakGroup"><xsd:annotation><xsd:documentation><h:div class="summary">A list of closely related peaks or peakGroups.</h:div><h:div class="description">Distinguish between<h:tt>peakList</h:tt>(primarily a navigational container) and<h:tt>peakGroup</h:tt>where the peaks (or groups) have some close relation not shared by all peaks. All descendants must use consistent units.</h:div><h:div class="curation">2005-11-22. added atomRefs, bondRefs and moleculeRefs and deprecated
atom, bond, molecule children</h:div><h:div class="example" href="peakGroup1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0"><xsd:annotation><xsd:documentation><h:div class="summary">Allows<h:i>inter alia</h:i>the provenance of the peak assignment to be recorde.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="peak"/><xsd:element ref="peakGroup"/><xsd:element ref="atom"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-22. DEPRECATED; use atomRefs</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="bond"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-22. DEPRECATED; use bondRefs</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="molecule"><xsd:annotation><xsd:documentation><h:div class="curation">2005-11-22. DEPRECATED; use moleculeRefs</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="peakHeight"/><xsd:attributeGroup ref="peakMultiplicity"/><xsd:attributeGroup ref="peakShape"/><xsd:attributeGroup ref="integral"/><xsd:attributeGroup ref="peakUnits"/><xsd:attributeGroup ref="xMin"/><xsd:attributeGroup ref="xMax"/><xsd:attributeGroup ref="xValue"/><xsd:attributeGroup ref="xWidth"/><xsd:attributeGroup ref="xUnits"/><xsd:attributeGroup ref="yMin"/><xsd:attributeGroup ref="yMax"/><xsd:attributeGroup ref="yValue"/><xsd:attributeGroup ref="yWidth"/><xsd:attributeGroup ref="yUnits"/><xsd:attributeGroup ref="atomRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Atoms contributing to this peak</h:div><h:div class="description">The primary set of atoms responsible for
the peak such as an NMR peak. Coupling constants and similar splitting
should not use this but peakStructure. At present there is no substructure to this
attribute or concept and only one attribute is allowed. It may be
combined with bondRefs. Even single atoms should use atomRefs, not atomRef.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="bondRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Bonds contributing to this peak</h:div><h:div class="description">The primary set of bonds responsible for
the peak such as an IR frequency. At present there is no substructure to this
attribute or concept and only one attribute is allowed. It may be
combined with atomRefs.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="moleculeRefs"><xsd:annotation><xsd:documentation><h:div class="summary">Molecule(s) contributing to this peak</h:div><h:div class="description">The molecule or molecule responsible for
the peak. At present there is no substructure to this
attribute or concept and only one attribute is allowed. This might, for example,
be used to manage a mass spectrum or chromatogram</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element peakList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A list of peaks or peakGroups.</h:div><h:div class="description">Distinguish between<h:tt>peakList</h:tt>(primarily a navigational container) and<h:tt>peakGroup</h:tt>where the peaks (or groups) have some close relation not shared by all peaks. All peaks and peakGroups should use the same units.</h:div><h:div class="example" href="peakList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="peakList" id="el.peakList"><xsd:annotation><xsd:documentation><h:div class="summary">A list of peaks or peakGroups.</h:div><h:div class="description">Distinguish between<h:tt>peakList</h:tt>(primarily a navigational container) and<h:tt>peakGroup</h:tt>where the peaks (or groups) have some close relation not shared by all peaks. All peaks and peakGroups should use the same units.</h:div><h:div class="example" href="peakList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0"><xsd:annotation><xsd:documentation><h:div class="summary">Allows<h:i>inter alia</h:i>the provenance of the peak assignment to be recorde.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="peak"/><xsd:element ref="peakGroup"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element plane3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A plane in 3-space.</h:div><h:div class="description">An oriented plane of indefinite extent.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="plane3" id="el.plane3"><xsd:annotation><xsd:documentation><h:div class="summary">A plane in 3-space.</h:div><h:div class="description">An oriented plane of indefinite extent.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="plane3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element point3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A point in 3-space.</h:div><h:div class="description"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="point3" id="el.point3"><xsd:annotation><xsd:documentation><h:div class="summary">A point in 3-space.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="point3Type"><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="units"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element potential
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An explicit potential.</h:div><h:div class="description">This represents the actual function for the potential (i.e. with explicit values) rather than the functional form, which will normally be referenced from this.</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="potential" id="el.potential"><xsd:annotation><xsd:documentation><h:div class="summary">An explicit potential.</h:div><h:div class="description">This represents the actual function for the potential (i.e. with explicit values) rather than the functional form, which will normally be referenced from this.</h:div><h:div class="example" href="potential1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="arg"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="form"/></xsd:complexType></xsd:element>
Element potentialForm
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The functional form of a potential.</h:div><h:div class="description">This has generic arguments and parameters rather than explicit ones. It is essentially a mathematical function, expressed currently in reverse Polish notation.</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="potentialForm" id="el.potentialForm"><xsd:annotation><xsd:documentation><h:div class="summary">The functional form of a potential.</h:div><h:div class="description">This has generic arguments and parameters rather than explicit ones. It is essentially a mathematical function, expressed currently in reverse Polish notation.</h:div><h:div class="example" href="potential1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><!--
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="annotation"/>
</xsd:choice>
--><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="arg"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="parameter"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="1"><xsd:element ref="expression"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="name"/></xsd:complexType></xsd:element>
Element potentialList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for explicit potentials.</h:div><h:div class="description">Experimental.</h:div><h:div class="example" href="potential1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A product within a productList.</h:div><h:div class="description"><h:tt>product</h:tt>describes a product species which is produced in a reaction. See<h:tt>reactant</h:tt>for discussion of catalysis and solvents.</h:div><h:div class="example" href="product1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="product" id="el.product"><xsd:annotation><xsd:documentation><h:div class="summary">A product within a productList.</h:div><h:div class="description"><h:tt>product</h:tt>describes a product species which is produced in a reaction. See<h:tt>reactant</h:tt>for discussion of catalysis and solvents.</h:div><h:div class="example" href="product1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div class="description"><h:p>A product will normally be identified by name(s), formula, or molecule and at least one of these should normally be given. Amount(s) of product can be given after this identification and can describe mass, volume, percent yield, etc. but not stoichiometry</h:p></h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="identifier" minOccurs="0"/><xsd:element ref="label" minOccurs="0"/><xsd:element ref="name" minOccurs="0"/></xsd:choice><xsd:element ref="molecule" minOccurs="0" maxOccurs="1"/><xsd:element ref="electron" minOccurs="0" maxOccurs="1"/><xsd:element ref="substance" minOccurs="0" maxOccurs="1"/><xsd:element ref="substanceList" minOccurs="0" maxOccurs="1"/><xsd:element ref="formula" minOccurs="0" maxOccurs="1"/><xsd:element ref="amount" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/><xsd:attributeGroup ref="count"/><xsd:attributeGroup ref="state"/></xsd:complexType></xsd:element>
Element substance
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A chemical substance.</h:div><h:div class="description"><h:tt>substance</h:tt>represents a<h:i>chemical substance</h:i>which is deliberately very general. It can represent things that may or may not be molecules, can and cannot be stored in bottles and may or may not be microscopic. Solutions and mixtures can be described by _substanceList_s of substances. The<h:tt>type</h:tt>attribute can be used to give qualitative information characterising the substance ("granular", "90%", etc.) and _role_ to describe the role in process ("desiccant", "support", etc.). There is currently no controlled vocabulary. Note that<h:tt>reaction</h:tt>is likely to have more precise semantics. The amount of a substance is controlled by the optional _amount_ child.</h:div><h:div class="example" href="substance1.xml"/>
<h:div class="curation"><h:p>Added property as a child 2002-12-29</h:p></h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="substance" id="el.substance"><xsd:annotation><xsd:documentation><h:div class="summary">A chemical substance.</h:div><h:div class="description"><h:tt>substance</h:tt>represents a<h:i>chemical substance</h:i>which is deliberately very general. It can represent things that may or may not be molecules, can and cannot be stored in bottles and may or may not be microscopic. Solutions and mixtures can be described by _substanceList_s of substances. The<h:tt>type</h:tt>attribute can be used to give qualitative information characterising the substance ("granular", "90%", etc.) and _role_ to describe the role in process ("desiccant", "support", etc.). There is currently no controlled vocabulary. Note that<h:tt>reaction</h:tt>is likely to have more precise semantics. The amount of a substance is controlled by the optional _amount_ child.</h:div><h:div class="example" href="substance1.xml"/></xsd:documentation><xsd:documentation><h:div class="curation"><h:p>Added property as a child 2002-12-29</h:p></h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="amount" minOccurs="0"/><xsd:choice><xsd:element ref="molecule" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="property" minOccurs="0" maxOccurs="unbounded"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific"><h:tt>role</h:tt>depends on context, and indicates some purpose associated with the substance. It might indicate 'catalyst', 'solvent', 'antoxidant', etc. but is not limited to any vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="count"/><xsd:attributeGroup ref="state"/></xsd:complexType></xsd:element>
Element substanceList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A list of chemical substances.</h:div><h:div class="description">Deliberately very general - see substance. substanceList is designed to manage solutions, mixtures, etc. and there is a small enumerated controlled vocabulary, but this can be extended through dictionaries.<h:p>substanceList can have an amount child. This can indicate the amount of a solution or mixture; this example describes 100 ml of 0.1M NaOH(aq). Although apparently longwinded it is precise and fully machine-interpretable</h:p></h:div><h:div class="curation">Added role attribute, 2003-03-12.</h:div><h:div class="example" href="substanceList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div>
Source
<xsd:element name="substanceList" id="el.substanceList"><xsd:annotation><xsd:documentation><h:div class="summary">A list of chemical substances.</h:div><h:div class="description">Deliberately very general - see substance. substanceList is designed to manage solutions, mixtures, etc. and there is a small enumerated controlled vocabulary, but this can be extended through dictionaries.<h:p>substanceList can have an amount child. This can indicate the amount of a solution or mixture; this example describes 100 ml of 0.1M NaOH(aq). Although apparently longwinded it is precise and fully machine-interpretable</h:p></h:div><h:div class="curation">Added role attribute, 2003-03-12.</h:div><h:div class="example" href="substanceList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="amount" minOccurs="0"/><!-- <xsd:choice>--><xsd:element ref="substance" minOccurs="0" maxOccurs="unbounded"/><!-- PMR 2003-01-26
<xsd:sequence>
<xsd:element ref="scalar" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="array" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="matrix" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="list" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
--><xsd:element ref="propertyList" minOccurs="0"/><!-- </xsd:choice>--></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="substanceListType"/><xsd:attributeGroup ref="role"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element productList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more products.</h:div><h:div class="description"><h:p><h:tt>productList</h:tt>can contain several products. These may be related in several ways, including<h:ul><h:li>single list of products</h:li><h:li>grouping of products of parallel reactions</h:li></h:ul>.
A productList can contain nested productLists. The semantics of this are currently undefined.</h:p></h:div><h:div class="example" href="productList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="productList" id="el.productList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more products.</h:div><h:div class="description"><h:p><h:tt>productList</h:tt>can contain several products. These may be related in several ways, including<h:ul><h:li>single list of products</h:li><h:li>grouping of products of parallel reactions</h:li></h:ul>.
A productList can contain nested productLists. The semantics of this are currently undefined.</h:p></h:div><h:div class="example" href="productList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="productList"/><xsd:element ref="product"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/><xsd:attributeGroup ref="count"><xsd:annotation><xsd:documentation><h:div class="specific">The number of copies of the productList involved in the stoichiometric reaction. Probably not useful for simple reactions but could be used for parallel reactions.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element reactant
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reactant within a reactantList.</h:div><h:div class="description"><h:tt>reactant</h:tt>describes a reactant species which takes part in a reaction. Catalysts and supports are not normally classified as reactants, but this is subjective. Enzymes (or parts of enzymes) may well be reactants, as could be substances which underwent chemical change but were restored to their original state.<h:tt>reactant</h:tt>is a powerful concept as it can support stoichiometry (atom and molecule counting), mapping (for mechanisms), etc. Solvents are best contained within substanceList.</h:div><h:div class="example" href="reactant1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="reactant" id="el.reactant"><xsd:annotation><xsd:documentation><h:div class="summary">A reactant within a reactantList.</h:div><h:div class="description"><h:tt>reactant</h:tt>describes a reactant species which takes part in a reaction. Catalysts and supports are not normally classified as reactants, but this is subjective. Enzymes (or parts of enzymes) may well be reactants, as could be substances which underwent chemical change but were restored to their original state.<h:tt>reactant</h:tt>is a powerful concept as it can support stoichiometry (atom and molecule counting), mapping (for mechanisms), etc. Solvents are best contained within substanceList.</h:div><h:div class="example" href="reactant1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div>A reactant will normally be identified by name(s), formula, or molecule and at least one of these should normally be given. Amount(s) of reactant can be given after this identification and can describe mass, volume, etc. but not stoichiometr.</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="identifier"/><xsd:element ref="label"/><xsd:element ref="name"/></xsd:choice><xsd:element ref="molecule" minOccurs="0" maxOccurs="1"/><xsd:element ref="electron" minOccurs="0" maxOccurs="1"/><xsd:element ref="substance" minOccurs="0" maxOccurs="1"/><xsd:element ref="substanceList" minOccurs="0" maxOccurs="1"/><xsd:element ref="formula" minOccurs="0" maxOccurs="1"/><xsd:element ref="amount" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">The role of the reactant within a reactantList. Semantics are not yet controlled but could be limiting, oxidant, etc. TODO: a reactant might have multiple roles so this may have to become an element.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="count"><xsd:annotation><xsd:documentation><h:div class="specific">The number of copies of the reactant involved in the stoichiometric reaction. Could be non-integer but should not be used for actual ratios of materials added (for which amount should be used).</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="state"/></xsd:complexType></xsd:element>
Element reactantList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more reactants.</h:div><h:div class="description"><h:p><h:tt>reactantList</h:tt>can contain several reactants. These may be related in several ways, including<h:ul><h:li>lists of related reactants</h:li><h:li>reactant schemes</h:li><h:li>multi-step reactants</h:li><h:li>parallel and/or coupled reactants</h:li></h:ul>.
A reactantList can contain nested reactantLists. The semantics of this are currently undefined.</h:p></h:div><h:div class="example" href="reactantList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="reactantList" id="el.reactantList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more reactants.</h:div><h:div class="description"><h:p><h:tt>reactantList</h:tt>can contain several reactants. These may be related in several ways, including<h:ul><h:li>lists of related reactants</h:li><h:li>reactant schemes</h:li><h:li>multi-step reactants</h:li><h:li>parallel and/or coupled reactants</h:li></h:ul>.
A reactantList can contain nested reactantLists. The semantics of this are currently undefined.</h:p></h:div><h:div class="example" href="reactantList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="name" minOccurs="0" maxOccurs="1"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="reactantList"/><xsd:element ref="reactant"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="role"/><xsd:attributeGroup ref="count"/></xsd:complexType></xsd:element>
Element reaction
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A chemical reaction or reaction step.</h:div><h:div class="description"><h:p><h:tt>reaction</h:tt>is a container for reactants, products, conditions, properties and possibly other information relating to the reaction, often within a reactionList. Partial semantics exist:<h:ul><h:li><h:b>name</h:b>the name(s) of the reaction</h:li><h:li><h:b>reactantList</h:b>(normally only one) the grouped reactants</h:li><h:li><h:b>spectatorList</h:b>substances with well-defined chemistry which are involved in the reaction but do not change. Examples are side groups in proteins, cofactors, etc. The division between specattor and substance is subjective.</h:li><h:li><h:b>substance</h:b>or<h:b>substanceList</h:b>substances present in the reaction but not classified as reactants. Examples might be enzymes, catalysts, solvents, supports, workup, etc.</h:li><h:li><h:b>condition</h:b>conditions of the reaction. These may be text strings, but ideally will have clearer semantics such as scalars for temperature, etc.</h:li><h:li><h:b>productList</h:b>the grouped products. This allows for parallel reactions or other semantics.</h:li><h:li><h:b>property</h:b>properties (often physical) associated with the reaction. Examples might be heat of formation, kinetics or equilibrium constant.</h:li></h:ul></h:p></h:div><h:div><h:p>Reaction normally refers to an overall reaction or a step within a reactionList. For a complex "reaction", such as in enzymes or chain reactions, it may be best to use<h:tt>reactionScheme</h:tt>to hold the overall<h:tt>reaction</h:tt>and a<h:tt>reactionList</h:tt>of the individual<h:tt>reaction</h:tt>steps.</h:p></h:div><h:div class="example" href="reaction1.xml"/><h:div class="example" href="reaction9a.xml"/><h:div class="example" href="reaction9b.xml"/><h:div class="example" href="reaction10a.xml"/><h:div class="example" href="reaction10b.xml"/><h:div class="example" href="reaction11.xml"/>
<h:div class="summary">A reference to a map providing mappings between atoms</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking atoms. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of atoms are of equal size and have 1:1 mapping between each id. This is another way of saying that the atoms mapped by a given ID are "the same atom".</h:div>
<h:div class="summary">A reference to a map providing mappings between bonds</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking bonds. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of bonds are of equal size and have 1:1 mapping between each id. This is another way of saying that the bonds mapped by a given ID are "the same bond".</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A reference to a map providing mappings between electrons</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking electrons. The topology of the linking is defined by the application - it could be reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of electrons are of equal size and have 1:1 mapping between each id. This is another way of saying that the electrons mapped by a given ID are "the same electron".</h:div>
<h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div>
Source
<xsd:element name="reaction" id="el.reaction"><xsd:annotation><xsd:documentation><h:div class="summary">A chemical reaction or reaction step.</h:div><h:div class="description"><h:p><h:tt>reaction</h:tt>is a container for reactants, products, conditions, properties and possibly other information relating to the reaction, often within a reactionList. Partial semantics exist:<h:ul><h:li><h:b>name</h:b>the name(s) of the reaction</h:li><h:li><h:b>reactantList</h:b>(normally only one) the grouped reactants</h:li><h:li><h:b>spectatorList</h:b>substances with well-defined chemistry which are involved in the reaction but do not change. Examples are side groups in proteins, cofactors, etc. The division between specattor and substance is subjective.</h:li><h:li><h:b>substance</h:b>or<h:b>substanceList</h:b>substances present in the reaction but not classified as reactants. Examples might be enzymes, catalysts, solvents, supports, workup, etc.</h:li><h:li><h:b>condition</h:b>conditions of the reaction. These may be text strings, but ideally will have clearer semantics such as scalars for temperature, etc.</h:li><h:li><h:b>productList</h:b>the grouped products. This allows for parallel reactions or other semantics.</h:li><h:li><h:b>property</h:b>properties (often physical) associated with the reaction. Examples might be heat of formation, kinetics or equilibrium constant.</h:li></h:ul></h:p></h:div><h:div><h:p>Reaction normally refers to an overall reaction or a step within a reactionList. For a complex "reaction", such as in enzymes or chain reactions, it may be best to use<h:tt>reactionScheme</h:tt>to hold the overall<h:tt>reaction</h:tt>and a<h:tt>reactionList</h:tt>of the individual<h:tt>reaction</h:tt>steps.</h:p></h:div><h:div class="example" href="reaction1.xml"/><h:div class="example" href="reaction9a.xml"/><h:div class="example" href="reaction9b.xml"/><h:div class="example" href="reaction10a.xml"/><h:div class="example" href="reaction10b.xml"/><h:div class="example" href="reaction11.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div><h:p>The semantics of the content model are</h:p><h:ul><h:li>metadataList for general metadata</h:li><h:li>label for classifying or describing the reaction (e.g. "hydrolysis")</h:li><h:li>identifier for unique identification. This could be a classification such as EC (enzyme commission) or an IChI-like string generated from the components.</h:li><h:li>these are followed by the possible components of the reaction and/or a reactionList of further details.</h:li></h:ul>.</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="label" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="name" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="identifier" minOccurs="0" maxOccurs="unbounded"/></xsd:choice><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:element ref="reactiveCentre" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="mechanism" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="reactantList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="spectatorList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="substanceList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="conditionList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="transitionState" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="productList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="propertyList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="map" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="object" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div>This allows any objects to be attached to the reaction, but particularly graphical primitives such as lines, arrows, etc. These should be provided as elements where possible (e.g. SVG) and should have references to the chemical objects they interact with (i.e. not simply relying on geometry). Markers with IDs can be included as part of the graphics object and their ids linked to the chemical elements using<h:tt>link</h:tt>.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="reactionFormat"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="reactionRole"/><xsd:attributeGroup ref="reactionType"/><xsd:attributeGroup ref="state"/><xsd:attributeGroup ref="atomMap"/><xsd:attributeGroup ref="electronMap"/><xsd:attributeGroup ref="bondMap"/><xsd:attributeGroup ref="yield"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>The yield of the reaction. Note that this lies in the range 0-1.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element reactiveCentre
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The reactiveCentre in a reaction.</h:div><h:div class="description">This describes the set(s) of bonds and atoms involved in the reaction. The semantics are flexible, but a common usage would be to create atomSet(s) and bondSet(s) mapping to groups which undergo changes.</h:div><h:div class="example" href="reactiveCentre1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="reactiveCentre" id="el.reactiveCentre"><xsd:annotation><xsd:documentation><h:div class="summary">The reactiveCentre in a reaction.</h:div><h:div class="description">This describes the set(s) of bonds and atoms involved in the reaction. The semantics are flexible, but a common usage would be to create atomSet(s) and bondSet(s) mapping to groups which undergo changes.</h:div><h:div class="example" href="reactiveCentre1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="description" minOccurs="0"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="atomTypeList"/><xsd:element ref="bondTypeList"/><xsd:element ref="atomSet"/><xsd:element ref="bondSet"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element spectatorList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for spectators in a reaction.</h:div><h:div class="description"/><h:div class="example" href="spectatorList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="spectatorList" id="el.spectatorList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for spectators in a reaction.</h:div><h:div class="description"/><h:div class="example" href="spectatorList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence maxOccurs="unbounded"><xsd:element ref="spectator"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element spectator
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A spectator object in a reaction.</h:div><h:div class="description">Objects are often present during a reaction which are not formally involved in bond breaking/formation and which are not modified during the reaction. They may be catalysts, but may also be objects which in some way constrain or help the reaction to take place (surfaces, micelles, groups in enzyme active sites, etc.). In some cases molecules present in a reaction mixture may act as spectators in steps in which they are not transformed.</h:div><h:div class="example" href="spectator1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="spectator" id="el.spectator"><xsd:annotation><xsd:documentation><h:div class="summary">A spectator object in a reaction.</h:div><h:div class="description">Objects are often present during a reaction which are not formally involved in bond breaking/formation and which are not modified during the reaction. They may be catalysts, but may also be objects which in some way constrain or help the reaction to take place (surfaces, micelles, groups in enzyme active sites, etc.). In some cases molecules present in a reaction mixture may act as spectators in steps in which they are not transformed.</h:div><h:div class="example" href="spectator1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="label"/><xsd:element ref="molecule"/><xsd:element ref="object"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="role"><xsd:annotation><xsd:documentation><h:div class="specific">No controlled vocabulary. Examples could be 'host', 'hydrophobic ligand', 'charge-stabilizer', etc..</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element transitionState
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The transition state in a reaction.</h:div><h:div class="description"><h:p>This will normally contain a<h:tt>molecule</h:tt>which in its 2D representation will have partial bonds. These are yet to be formalized for the<h:tt>molecule</h:tt>element.</h:p><h:p>Although spectators may stabilise or otherwise interact with the transitionState they are not contained within it.</h:p><h:p>A<h:tt>propertyList</h:tt>is provided to capture transitionState properties.</h:p><h:p>Still experimental.</h:p></h:div><h:div class="example" href="transitionState1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="transitionState" id="el.transitionState"><xsd:annotation><xsd:documentation><h:div class="summary">The transition state in a reaction.</h:div><h:div class="description"><h:p>This will normally contain a<h:tt>molecule</h:tt>which in its 2D representation will have partial bonds. These are yet to be formalized for the<h:tt>molecule</h:tt>element.</h:p><h:p>Although spectators may stabilise or otherwise interact with the transitionState they are not contained within it.</h:p><h:p>A<h:tt>propertyList</h:tt>is provided to capture transitionState properties.</h:p><h:p>Still experimental.</h:p></h:div><h:div class="example" href="transitionState1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="molecule"/><xsd:element ref="propertyList" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element reactionList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more reactions or reactionSchemes with no interrelations.</h:div><h:div class="description">A reactionList aggregates reactions and reactionSchemes but implies no semantics. The most common uses are to create small collections of reactions (e.g. databases or publications).</h:div><h:div class="example" href="reactionList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="reactionList" id="el.reactionList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more reactions or reactionSchemes with no interrelations.</h:div><h:div class="description">A reactionList aggregates reactions and reactionSchemes but implies no semantics. The most common uses are to create small collections of reactions (e.g. databases or publications).</h:div><h:div class="example" href="reactionList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div/></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="reactionScheme" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="reaction" minOccurs="0" maxOccurs="unbounded"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="name"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element reactionScheme
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for two or more related reactions and their relationships.</h:div><h:div class="description">Where reactions are closely related (and often formally dependent on each other) they should be contained within the reactionStepList of a reactionScheme. The semantics which have informed this design include:<h:ul><h:li>Steps within an organic synthesis.</h:li><h:li>Two or more individual (primitive) steps provding the detailed mechanism for an overall reaction.</h:li><h:li>Coupled or sequential reactions within biochemical pathways.</h:li></h:ul><h:p>This design is general because "reaction" is used in several ways. A biochemical pathway (e.g. oxidation of glucose to CO2 and water) involves many coupled enzyme reactions proceeding both in parallel and in sequence. Each of these steps ("reactions" in their own right) is itself complex and can include several mechanistics steps which are themselves reactions with products, reactants, etc.<h:tt>reactionScheme</h:tt>can therefore include reactionStepLists (with more reactionScheme children) which provide a more detailed view of the individual components.</h:p><h:p>Where a set of reactions are primitives...</h:p></h:div><h:div class="example" href="reactionScheme1.xml"/><h:div class="example" href="reactionScheme3.xml"/><h:div class="example" href="reactionScheme4a.xml"/><h:div class="example" href="reactionScheme4b.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Type of the reaction.</h:div>
Source
<xsd:element name="reactionScheme" id="el.reactionScheme"><xsd:annotation><xsd:documentation><h:div class="summary">A container for two or more related reactions and their relationships.</h:div><h:div class="description">Where reactions are closely related (and often formally dependent on each other) they should be contained within the reactionStepList of a reactionScheme. The semantics which have informed this design include:<h:ul><h:li>Steps within an organic synthesis.</h:li><h:li>Two or more individual (primitive) steps provding the detailed mechanism for an overall reaction.</h:li><h:li>Coupled or sequential reactions within biochemical pathways.</h:li></h:ul><h:p>This design is general because "reaction" is used in several ways. A biochemical pathway (e.g. oxidation of glucose to CO2 and water) involves many coupled enzyme reactions proceeding both in parallel and in sequence. Each of these steps ("reactions" in their own right) is itself complex and can include several mechanistics steps which are themselves reactions with products, reactants, etc.<h:tt>reactionScheme</h:tt>can therefore include reactionStepLists (with more reactionScheme children) which provide a more detailed view of the individual components.</h:p><h:p>Where a set of reactions are primitives...</h:p></h:div><h:div class="example" href="reactionScheme1.xml"/><h:div class="example" href="reactionScheme3.xml"/><h:div class="example" href="reactionScheme4a.xml"/><h:div class="example" href="reactionScheme4b.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div class="description"><h:p>The semantics of the content model are</h:p><h:ul><h:li>metadataList for general metadata</h:li><h:li>label for classifying or describing the reaction (e.g. "hydrolysis")</h:li><h:li>identifier for unique identification. This could be a classification such as EC (enzyme commission) or an IChI-like string generated from the components.</h:li><h:li>these are followed by the possible components of the reaction and/or a reactionList of further details.</h:li></h:ul></h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="label"/><xsd:element ref="name"/><xsd:element ref="identifier"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="reaction"/><xsd:element ref="reactionStepList"/><xsd:element ref="reactionScheme"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="reactionRole"/><xsd:attributeGroup ref="reactionType"/><xsd:attributeGroup ref="state"/><xsd:attributeGroup ref="reactionFormat"/></xsd:complexType></xsd:element>
Element reactionStepList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more related reactionSteps.</h:div><h:div class="description"><h:p><h:tt>reactionStepList</h:tt>is always contained within reactionScheme and is designed to manage "sub-reactions" which have close relationships. These will often involve reactions which, taken together, describe a higher level reaction or reaction type. Examples are:<h:ul><h:li>biochemical pathways</h:li><h:li>synthetic reaction schemes</h:li><h:li>multi-step reactions</h:li><h:li>parallel and/or coupled reactions</h:li></h:ul>.
A reactionStepList contains reactionSteps (each of which contains reactions and/or reactionSchemes (e.g. where part of the process is known in greater detail)). It may not directly contain child reactionStepLists.</h:p><h:p>The child reactionSteps can have attributes such as yield and ratio which describe the relationship of the component steps.</h:p><h:p>Guidance on use:<h:ul><h:li>reactionScheme describes a complex of reactions with metadata, one (or more) overall reactions and a reactionStepList with the overall component reactions.</h:li><h:li>reactionStepList aggregates and structures the individual subreactions.</h:li><h:li>reactionList is a container for reactions and reactionSchemes with no semantics (e.g. a book or database of selected reactions).</h:li></h:ul></h:p></h:div><h:div class="example" href="reactionStepList1.xml"/><h:div class="example" href="reactionStepList3.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:element name="reactionStepList" id="el.reactionStepList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more related reactionSteps.</h:div><h:div class="description"><h:p><h:tt>reactionStepList</h:tt>is always contained within reactionScheme and is designed to manage "sub-reactions" which have close relationships. These will often involve reactions which, taken together, describe a higher level reaction or reaction type. Examples are:<h:ul><h:li>biochemical pathways</h:li><h:li>synthetic reaction schemes</h:li><h:li>multi-step reactions</h:li><h:li>parallel and/or coupled reactions</h:li></h:ul>.
A reactionStepList contains reactionSteps (each of which contains reactions and/or reactionSchemes (e.g. where part of the process is known in greater detail)). It may not directly contain child reactionStepLists.</h:p><h:p>The child reactionSteps can have attributes such as yield and ratio which describe the relationship of the component steps.</h:p><h:p>Guidance on use:<h:ul><h:li>reactionScheme describes a complex of reactions with metadata, one (or more) overall reactions and a reactionStepList with the overall component reactions.</h:li><h:li>reactionStepList aggregates and structures the individual subreactions.</h:li><h:li>reactionList is a container for reactions and reactionSchemes with no semantics (e.g. a book or database of selected reactions).</h:li></h:ul></h:p></h:div><h:div class="example" href="reactionStepList1.xml"/><h:div class="example" href="reactionStepList3.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div><h:p>The<h:tt>name</h:tt>applies to the overall schema of reactions.<h:tt>label</h:tt>is for additional textual information and classification.<h:tt>reactionStepList</h:tt>normally contains<h:tt>reactionStep</h:tt>s.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="name"/><xsd:element ref="label"/></xsd:choice><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:element ref="reactionStep"/></xsd:sequence></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="type"/><xsd:attributeGroup ref="reactionFormat"/></xsd:complexType></xsd:element>
Element reactionStep
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A child of reactionStepList and a container for reaction or reactionScheme.</h:div><h:div class="description"><h:p><h:tt>reactionStep</h:tt>is always contained within reactionStepList and is designed to manage "sub-reactions" which have close relationships. These will often involve reactions which, taken together, describe a higher level reaction or reaction type. Examples are:<h:ul><h:li>biochemical pathways</h:li><h:li>synthetic reaction schemes</h:li><h:li>multi-step reactions</h:li><h:li>parallel and/or coupled reactions</h:li></h:ul>.
A reactionStep normally contains a single reaction or reactionScheme. It can have attributes such as yield and ratio which can be used by the parent reactionStepList.</h:p></h:div><h:div class="example" href="reactionStepList4.xml"/><h:div class="example" href="reactionStepList5a.xml"/><h:div class="example" href="reactionStepList5b.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A ratio in the range 0 to 1.</h:div><h:div class="description">Currently used for ratios between brached reactions but re-usable for other concepts.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div>
Source
<xsd:element name="reactionStep" id="el.reactionStep"><xsd:annotation><xsd:documentation><h:div class="summary">A child of reactionStepList and a container for reaction or reactionScheme.</h:div><h:div class="description"><h:p><h:tt>reactionStep</h:tt>is always contained within reactionStepList and is designed to manage "sub-reactions" which have close relationships. These will often involve reactions which, taken together, describe a higher level reaction or reaction type. Examples are:<h:ul><h:li>biochemical pathways</h:li><h:li>synthetic reaction schemes</h:li><h:li>multi-step reactions</h:li><h:li>parallel and/or coupled reactions</h:li></h:ul>.
A reactionStep normally contains a single reaction or reactionScheme. It can have attributes such as yield and ratio which can be used by the parent reactionStepList.</h:p></h:div><h:div class="example" href="reactionStepList4.xml"/><h:div class="example" href="reactionStepList5a.xml"/><h:div class="example" href="reactionStepList5b.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div><h:p>The<h:tt>name</h:tt>applies to the overall schema of reactions.<h:tt>label</h:tt>is for additional textual information and classification.<h:tt>reactionStepList</h:tt>normally contains<h:tt>reaction</h:tt>s but we make provision for nested reactionSchemes if required.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="name"/><xsd:element ref="label"/></xsd:choice><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="reactionScheme"/><xsd:element ref="reaction"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="yield"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>The yield of the reactionStep. Note that this lies in the range 0-1.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="ratio"><xsd:annotation><xsd:documentation><h:div class="specific"><h:p>The ratio of this step to one or more sibling steps. Note that this lies in the range 0-1. It is meaningless to use this unless there are siblings, in which case it refers to the relative molar fluxes through each. The "percentage yields" will need to be transformed to this range. There is no requirement that the sum of fluxes through a group of siblings sum to 1.0, though they should not sum to more.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element region
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A region of the system.</h:div><h:div class="description">Under development. A subdivision of the system to which special
protocols or properties may be attached. Typical regions could be defined by the
presence of atoms belonging to an atomSet or geometrical boundaries.</h:div><h:div class="note">A region element will not always contain other elements,
but may have references from other elements. It may create a protocol, e.g. atoms
within a region might be replaced by a continuum model or be subject to a field.
Semantics yet to be determined.</h:div><h:div>Regions can be created by the unions of two or more regions. This allows a region
to be built from a series of (say) spheres or boxes filling space.</h:div><h:div class="example" href="region1.xml"/>
<h:div class="summary">An atomSet describing the region.</h:div><h:div class="description">Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments.</h:div>
<h:div class="summary">A parallelipiped box.</h:div><h:div class="description">By default the box uses isometric Cartesians axes but can also be linked to lattice Vector. Any point falling within the box or on a boundary is within the regio.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A list of regions creating a union.</h:div><h:div class="description">The union of a series of regions produces a larger region (possibly disjoint). Any point belonging to any of the referenced regions is a member of this region.</h:div>
<h:div class="summary">A sphere.</h:div><h:div class="description">Currently describes a region. Any point falling within the sphere or on its surface is within the region.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="region" id="el.region"><xsd:annotation><xsd:documentation><h:div class="summary">A region of the system.</h:div><h:div class="description">Under development. A subdivision of the system to which special
protocols or properties may be attached. Typical regions could be defined by the
presence of atoms belonging to an atomSet or geometrical boundaries.</h:div><h:div class="note">A region element will not always contain other elements,
but may have references from other elements. It may create a protocol, e.g. atoms
within a region might be replaced by a continuum model or be subject to a field.
Semantics yet to be determined.</h:div><h:div>Regions can be created by the unions of two or more regions. This allows a region
to be built from a series of (say) spheres or boxes filling space.</h:div><h:div class="example" href="region1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence/><xsd:attributeGroup ref="sphere3"/><xsd:attributeGroup ref="box3"/><xsd:attributeGroup ref="atomSetRef"/><xsd:attributeGroup ref="regionRefs"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element sample
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An analytical or spectral sample.</h:div><h:div class="description">The<h:tt>sample</h:tt>should contain information on what things were in the sample and their roles. It can include<h:tt>molecule</h:tt>,<h:tt>substance</h:tt>and<h:tt>substanceList</h:tt>. Typical rolos include solvent, mulling agents, salt disks, molecular supports, etc. but should not cover apparatus or conditions.</h:div><h:div class="example" href="sample1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="sample" id="el.sample"><xsd:annotation><xsd:documentation><h:div class="summary">An analytical or spectral sample.</h:div><h:div class="description">The<h:tt>sample</h:tt>should contain information on what things were in the sample and their roles. It can include<h:tt>molecule</h:tt>,<h:tt>substance</h:tt>and<h:tt>substanceList</h:tt>. Typical rolos include solvent, mulling agents, salt disks, molecular supports, etc. but should not cover apparatus or conditions.</h:div><h:div class="example" href="sample1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="molecule"><xsd:annotation><xsd:documentation><h:div>A molecular description.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="substance"><xsd:annotation><xsd:documentation><h:div>A substance in the sample.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="substanceList"><xsd:annotation><xsd:documentation><h:div>A list of substances in the sample.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="state"/></xsd:complexType></xsd:element>
Element spectrum
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A spectrum and relevant data or metadata.</h:div><h:div class="description">The<h:tt>spectrum</h:tt>construct can hold<h:tt>metadataList</h:tt>,<h:tt>sample</h:tt>(which can contain molecule),<h:tt>conditionList</h:tt>(mainly for physical/chemical conditions, not instrumental),<h:tt>spectrumData</h:tt>for the actual data and instrumental settings/procedure and<h:tt>peakList</h:tt>for the assigned peaks. This approach puts the spectrum as the primary object of interest. It could also be possible to make<h:tt>spectrum</h:tt>a child of<h:tt>molecule</h:tt>(although a reference using<h:tt>ref</h:tt>might be preferable).</h:div><h:div class="example" href="spectrum1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div>
<h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">The type of the spectrum.</h:div>
Source
<xsd:element name="spectrum" id="el.spectrum"><xsd:annotation><xsd:documentation><h:div class="summary">A spectrum and relevant data or metadata.</h:div><h:div class="description">The<h:tt>spectrum</h:tt>construct can hold<h:tt>metadataList</h:tt>,<h:tt>sample</h:tt>(which can contain molecule),<h:tt>conditionList</h:tt>(mainly for physical/chemical conditions, not instrumental),<h:tt>spectrumData</h:tt>for the actual data and instrumental settings/procedure and<h:tt>peakList</h:tt>for the assigned peaks. This approach puts the spectrum as the primary object of interest. It could also be possible to make<h:tt>spectrum</h:tt>a child of<h:tt>molecule</h:tt>(although a reference using<h:tt>ref</h:tt>might be preferable).</h:div><h:div class="example" href="spectrum1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:choice minOccurs="0" maxOccurs="unbounded"><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="sample" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div>A (complete) description of the thing to which the spectrum relates. May contain<h:tt>molecule</h:tt>or<h:tt>substanceList</h:tt>. Solvents, mulls, etc should be described here.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="parameterList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="substanceList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="conditionList" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div>The conditions relating to the spectrum (complementary to substanceList.</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="spectrumData" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="peakList" minOccurs="0" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div>A list of peaks. This may occur independently of the xaxis/yaxis data.</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:choice><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="moleculeRef"><xsd:annotation><xsd:documentation><h:div class="specific">The molecule to which the spectrum refers.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="spectrumType"/><xsd:attributeGroup ref="format"/><xsd:attributeGroup ref="measurement"/><xsd:attributeGroup ref="ft"/><xsd:attributeGroup ref="state"><xsd:annotation><xsd:documentation><h:div class="specific">Although this may also be contained in the<h:tt>sample</h:tt>element it is useful to state it here. No default.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element spectrumData
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Data for the spectrum.</h:div><h:div class="description">This is primarily to record the data in interchangeable format and machine and manufacturers settings and can include other MLs in this area (AniML, SpectroML, etc.). We recommend ASCII representations of data and this is the only format that CMLSpect implementers have to support, but we also allow for the carriage of JCAMP and other data (in ML wrappers such as AniML). All numeric data should carry units and dictionary references if possible to allow for semantic interoperability.</h:div><h:div class="example" href="spectrumData1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="spectrumData" id="el.spectrumData"><xsd:annotation><xsd:documentation><h:div class="summary">Data for the spectrum.</h:div><h:div class="description">This is primarily to record the data in interchangeable format and machine and manufacturers settings and can include other MLs in this area (AniML, SpectroML, etc.). We recommend ASCII representations of data and this is the only format that CMLSpect implementers have to support, but we also allow for the carriage of JCAMP and other data (in ML wrappers such as AniML). All numeric data should carry units and dictionary references if possible to allow for semantic interoperability.</h:div><h:div class="example" href="spectrumData1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:sequence minOccurs="0" maxOccurs="1"><xsd:element ref="xaxis"><xsd:annotation><xsd:documentation><h:div>The x-axis/es, usually including the list of points at which data are recorded. Mandatory if y-axis data are given. Multiple x-axes are initially reserved for multiple scales rather than different measurements (for which an additional spectrum should be used).</h:div></xsd:documentation></xsd:annotation></xsd:element><xsd:element ref="yaxis" maxOccurs="unbounded"><xsd:annotation><xsd:documentation><h:div>The y-axis/es, usually including the list of points at which data are recorded. Mandatory if x-axis data are given. Multiple y-axes are initially reserved for multiple scales rather than different measurements (for which an additional spectrum should be used).</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/></xsd:complexType></xsd:element>
Element xaxis
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The x-axis.</h:div><h:div class="description">A container for all information relating to the x-axis (including scales, offsets, etc.) and the data themselves (in an<h:tt>array</h:tt>). Note: AniML uses "xValues" so avoid confusion with this.</h:div><h:div class="example" href="xaxis1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="xaxis" id="el.xaxis"><xsd:annotation><xsd:documentation><h:div class="summary">The x-axis.</h:div><h:div class="description">A container for all information relating to the x-axis (including scales, offsets, etc.) and the data themselves (in an<h:tt>array</h:tt>). Note: AniML uses "xValues" so avoid confusion with this.</h:div><h:div class="example" href="xaxis1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="array"><xsd:annotation><xsd:documentation><h:div>The x-data. These must match the y-data in number and order. There are tools to allow scaling and transformation (though unscaled data must be very carefully defined).</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="multiplierToData"/><xsd:attributeGroup ref="constantToData"/></xsd:complexType></xsd:element>
Element yaxis
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The y-axis.</h:div><h:div class="description">A container for all information relating to the y-axis (including scales, offsets, etc.) and the data themselves (in an<h:tt>array</h:tt>).</h:div><h:div class="example" href="yaxis1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="yaxis" id="el.yaxis"><xsd:annotation><xsd:documentation><h:div class="summary">The y-axis.</h:div><h:div class="description">A container for all information relating to the y-axis (including scales, offsets, etc.) and the data themselves (in an<h:tt>array</h:tt>).</h:div><h:div class="example" href="yaxis1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="array"><xsd:annotation><xsd:documentation><h:div>The y-data. These must match the x-data in number and order. There are tools to allow scaling and transformation (though unscaled data must be very carefully defined).</h:div></xsd:documentation></xsd:annotation></xsd:element></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="multiplierToData"/><xsd:attributeGroup ref="constantToData"/></xsd:complexType></xsd:element>
Element spectrumList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for one or more spectra.</h:div><h:div class="description"><h:p><h:tt>spectrumList</h:tt>can contain several spectra. These may be related in several ways, including<h:ul><h:li>lists of related spectra</h:li><h:li>bundle of common analytical spectra (NMR, IR, UV...)</h:li><h:li>repeat measurements</h:li></h:ul>.
A spectrumList can contain nested spectrumLists.</h:p></h:div><h:div class="example" href="spectrumList1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="spectrumList" id="el.spectrumList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for one or more spectra.</h:div><h:div class="description"><h:p><h:tt>spectrumList</h:tt>can contain several spectra. These may be related in several ways, including<h:ul><h:li>lists of related spectra</h:li><h:li>bundle of common analytical spectra (NMR, IR, UV...)</h:li><h:li>repeat measurements</h:li></h:ul>.
A spectrumList can contain nested spectrumLists.</h:p></h:div><h:div class="example" href="spectrumList1.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:annotation><xsd:documentation><h:div><h:tt>metadataList</h:tt>contains<h:tt>metadata</h:tt>.<h:tt>list</h:tt>is for experimental and other data.<h:tt>spectrumList</h:tt>normally contains<h:tt>spectrum</h:tt>s but we make provision for nested spectrumLists if required. The<h:tt>molecule</h:tt>s can be a set of reference molecules which occur in the<h:tt>spectrum</h:tt>s and can be referenced. This makes the spectrums more readable and normalizes data when molecules are used more than once.</h:div></xsd:documentation></xsd:annotation><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="list" minOccurs="0" maxOccurs="unbounded"/><xsd:choice><xsd:element ref="spectrumList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="spectrum" minOccurs="0" maxOccurs="unbounded"/></xsd:choice></xsd:sequence><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="ref"/><xsd:attributeGroup ref="moleculeRef"/></xsd:complexType></xsd:element>
Element sphere3
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A sphere in 3-space.</h:div><h:div class="description"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<h:div class="summary">An element to hold stmml data.</h:div><h:div class="description"><h:tt>stmml</h:tt>holds stmml data under a single
generic container. Other namespaces may be present as children.
No semantics implied.</h:div><h:div class="example" href="stmml1.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="stmml" id="el.stmml"><xsd:annotation><xsd:documentation><h:div class="summary">An element to hold stmml data.</h:div><h:div class="description"><h:tt>stmml</h:tt>holds stmml data under a single
generic container. Other namespaces may be present as children.
No semantics implied.</h:div><h:div class="example" href="stmml1.xml"/><!--
<h:div class="example" href="bad.stmml.xml">
<h:p>Note attribute (mistake) not in schema</h:p></h:div>
<h:div class="example" href="bad.stmml2.xml">
<h:p>Note bad name</h:p></h:div>
--></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence minOccurs="0" maxOccurs="unbounded"><xsd:any processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The complete system of components in a calculation.</h:div><h:div class="description">There is no controlled vocabulary.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">Dimensionality of a coordinate system.</h:div><h:div class="description">Note that this means that coordinates of higher dimensionality
are ignored or an error is flagged. Thus z3 and dimensionality='2' are incompatible.
At present higher dimensionalities than 3 (cf. Wondratschek) are not supported.
The labelling of the axes id not controlled. ?? should we have an explicit
attribute for labelling convention?.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Periodicity of the system.</h:div><h:div class="summary">This represents the number of dimensions (or coordinate axes) along periodic behaviour occurs and can be supported by symmetry operators or other transformations. Periodicity must never exceed dimensionality.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="system" id="el.system"><xsd:annotation><xsd:documentation><h:div class="summary">The complete system of components in a calculation.</h:div><h:div class="description">There is no controlled vocabulary.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/></xsd:sequence><xsd:attributeGroup ref="dimensionality"/><xsd:attributeGroup ref="periodicity"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element table
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A rectangular table of any quantities.</h:div><h:div class="description"><h:p>By default<h:tt>table</h:tt>represents a rectangular table of any simple quantities
representable as XSD or CML dataTypes. There are three layouts, columnwise, rowwise and
without markup. In all cases it is essential that the columns, whether explicit or
otherwise, are homogeneous within the column. Also the metadata for each column must
be given explicitly.<ul xmlns=""><li>columns:
There is a single<h:a href="el.arrayList">arrayList</h:a>child containing (homogeneous) child
elements (<h:a href="el.array">array</h:a>or<h:a href="el.list">list</h:a>of
size<h:tt>rows</h: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 or lists, which must all be of the same size.</li><li>rows: with explicit<tt>trow</tt>s. The metadata is carried in a<tt>theader</tt>element of size<tt>cols</tt>. Within each trow the data are contained in tcells</li><li>content: The metadata is carried in a<tt>theader</tt>element of size<tt>cols</tt>. data are contained in a single<tt>tableContent</tt>with columns moving fastest. Within the content the data are whitespace (or delimiter) separated.</li></ul>For
verification it is recommended that tables carry<h:tt>rows</h:tt>and<h:tt>columns</h:tt>attributes.
The type of the tables should also be carried in a<tt xmlns="">tableType</tt>attribute></h:p></h:div><h:div>Validity contraints (XPath expression in table context)<h:table><h:tr><h:th>type</h:th><h:th>@tableType</h:th><h:th>@rows</h:th><h:th>actual rowCount</h:th><h:th>@columns</h:th><h:th>actual columnCount</h:th><h:th>tableHeader</h:th><h:th>arrayList</h:th><h:th>tableRowList</h:th><h:th>tableContent</h:th></h:tr><h:tr><h:td>column based</h:td><h:td>columnBased</h:td><h:td>recommended</h:td><h:td>./arrayList/@size or arrayList/*[self::array or self::list]/@size</h:td><h:td>optional</h:td><h:td>./arrayList/@size or count(arrayList/*[self::array or self::list])</h:td><h:td>forbidden</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>forbidden</h:td></h:tr><h:tr><h:td>row based</h:td><h:td>rowBased</h:td><h:td>recommended</h:td><h:td>./tableRowList/@size or count(tableRowList/tableRow)</h:td><h:td>recommended</h:td><h:td>count(tableHeader/tableHeaderCell) or count(tableRowList/tableRow/tableCell)</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>required</h:td><h:td>forbidden</h:td></h:tr><h:tr><h:td>content based</h:td><h:td>contentBased</h:td><h:td>required</h:td><h:td>only by analysing tde table</h:td><h:td>recommended</h:td><h:td>count(tableHeader/tableHeaderCell)</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>forbidden</h:td><h:td>required</h:td></h:tr></h:table></h:div><h:div class="example" href="table1.xml"/><h:div class="example" href="table2.xml"/><h:div class="example" href="table3.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="table" id="el.table"><xsd:annotation><xsd:documentation><h:div class="summary">A rectangular table of any quantities.</h:div><h:div class="description"><h:p>By default<h:tt>table</h:tt>represents a rectangular table of any simple quantities
representable as XSD or CML dataTypes. There are three layouts, columnwise, rowwise and
without markup. In all cases it is essential that the columns, whether explicit or
otherwise, are homogeneous within the column. Also the metadata for each column must
be given explicitly.<ul xmlns=""><li>columns:
There is a single<h:a href="el.arrayList">arrayList</h:a>child containing (homogeneous) child
elements (<h:a href="el.array">array</h:a>or<h:a href="el.list">list</h:a>of
size<h:tt>rows</h: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 or lists, which must all be of the same size.</li><li>rows: with explicit<tt>trow</tt>s. The metadata is carried in a<tt>theader</tt>element of size<tt>cols</tt>. Within each trow the data are contained in tcells</li><li>content: The metadata is carried in a<tt>theader</tt>element of size<tt>cols</tt>. data are contained in a single<tt>tableContent</tt>with columns moving fastest. Within the content the data are whitespace (or delimiter) separated.</li></ul>For
verification it is recommended that tables carry<h:tt>rows</h:tt>and<h:tt>columns</h:tt>attributes.
The type of the tables should also be carried in a<tt xmlns="">tableType</tt>attribute></h:p></h:div><h:div>Validity contraints (XPath expression in table context)<h:table><h:tr><h:th>type</h:th><h:th>@tableType</h:th><h:th>@rows</h:th><h:th>actual rowCount</h:th><h:th>@columns</h:th><h:th>actual columnCount</h:th><h:th>tableHeader</h:th><h:th>arrayList</h:th><h:th>tableRowList</h:th><h:th>tableContent</h:th></h:tr><h:tr><h:td>column based</h:td><h:td>columnBased</h:td><h:td>recommended</h:td><h:td>./arrayList/@size or arrayList/*[self::array or self::list]/@size</h:td><h:td>optional</h:td><h:td>./arrayList/@size or count(arrayList/*[self::array or self::list])</h:td><h:td>forbidden</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>forbidden</h:td></h:tr><h:tr><h:td>row based</h:td><h:td>rowBased</h:td><h:td>recommended</h:td><h:td>./tableRowList/@size or count(tableRowList/tableRow)</h:td><h:td>recommended</h:td><h:td>count(tableHeader/tableHeaderCell) or count(tableRowList/tableRow/tableCell)</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>required</h:td><h:td>forbidden</h:td></h:tr><h:tr><h:td>content based</h:td><h:td>contentBased</h:td><h:td>required</h:td><h:td>only by analysing tde table</h:td><h:td>recommended</h:td><h:td>count(tableHeader/tableHeaderCell)</h:td><h:td>required</h:td><h:td>forbidden</h:td><h:td>forbidden</h:td><h:td>required</h:td></h:tr></h:table></h:div><h:div class="example" href="table1.xml"/><h:div class="example" href="table2.xml"/><h:div class="example" href="table3.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:choice><!-- columnwise arrays --><xsd:element ref="arrayList" minOccurs="0" maxOccurs="1"/><!-- OR header, followed by rows or content --><xsd:sequence><xsd:element ref="tableHeader" minOccurs="1" maxOccurs="1"/><xsd:choice><!-- rowwise rows --><xsd:element ref="tableRowList" minOccurs="0" maxOccurs="unbounded"/><!-- unmarked content --><xsd:element ref="tableContent" minOccurs="0" maxOccurs="1"/></xsd:choice></xsd:sequence></xsd:choice></xsd:sequence><xsd:attributeGroup ref="rows"/><xsd:attributeGroup ref="columns"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="tableType"/><!-- <xsd:attributeGroup ref="dataType"/> --><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element tableHeader
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Header for a table.</h:div><h:div class="description"><h:p>Used for rowBased or contentBased tables when it is mandatory.
Contains the metadata as tableHeaderCells which should match the (implicit) columns
in number and semantic type. It is forbidden for arrayList tables as each
array/list contains the metadata.</h:p></h:div><h:div class="example" href="table6.xml"/><h:div class="example" href="table7.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="tableHeader" id="el.tableHeader"><xsd:annotation><xsd:documentation><h:div class="summary">Header for a table.</h:div><h:div class="description"><h:p>Used for rowBased or contentBased tables when it is mandatory.
Contains the metadata as tableHeaderCells which should match the (implicit) columns
in number and semantic type. It is forbidden for arrayList tables as each
array/list contains the metadata.</h:p></h:div><h:div class="example" href="table6.xml"/><h:div class="example" href="table7.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="tableHeaderCell" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element tableHeaderCell
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Metadata for a column of a table.</h:div><h:div class="description">Only used when in rowBased or contentBased tables,
and then as a direct child of tableHeader.
There must be as many tableHeaderCells as there are
implicit columns in tableRowList or tableContent. These cells carry the metadata
and/or semantics for each column. These are similar to the attributes in<h:tt>array</h:tt>but without the lsist of minValue, errors etc. However they can (and should)
carry all the units metadata.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="tableHeaderCell" id="el.tableHeaderCell"><xsd:annotation><xsd:documentation><h:div class="summary">Metadata for a column of a table.</h:div><h:div class="description">Only used when in rowBased or contentBased tables,
and then as a direct child of tableHeader.
There must be as many tableHeaderCells as there are
implicit columns in tableRowList or tableContent. These cells carry the metadata
and/or semantics for each column. These are similar to the attributes in<h:tt>array</h:tt>but without the lsist of minValue, errors etc. However they can (and should)
carry all the units metadata.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><!-- empty --><xsd:sequence minOccurs="0" maxOccurs="0"></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="constantToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="multiplierToSI"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with unitType</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="unitType"><xsd:annotation><xsd:documentation><h:div class="specific">Alternative to units</h:div><h:div class="description">Must be used in conjunction with multiplierToSI and/or constantToSI</h:div><h:div class="curation">2005-10-26: added</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Element tableRowList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">List of rows in rowBased table.</h:div><h:div class="description"><h:p>Metadata for rows must be defined in tableHeader.</h:p></h:div><h:div class="example" href="table2.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="tableRowList" id="el.tableRowList"><xsd:annotation><xsd:documentation><h:div class="summary">List of rows in rowBased table.</h:div><h:div class="description"><h:p>Metadata for rows must be defined in tableHeader.</h:p></h:div><h:div class="example" href="table2.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="tableRow" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element tableRow
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A row in a rowBased table.</h:div><h:div class="description">A direct child of tableRowList containing tableCells.
At present all tableRows in a tableRowList must have the same count of tableCells
and their semantics must correspond to the tableHeader in the table. No cells can be omitted
and there is no spanning of cells. There is no need for a size attribute as the count is simply<h:tt>count(tableCell)</h:tt>.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="tableRow" id="el.tableRow"><xsd:annotation><xsd:documentation><h:div class="summary">A row in a rowBased table.</h:div><h:div class="description">A direct child of tableRowList containing tableCells.
At present all tableRows in a tableRowList must have the same count of tableCells
and their semantics must correspond to the tableHeader in the table. No cells can be omitted
and there is no spanning of cells. There is no need for a size attribute as the count is simply<h:tt>count(tableCell)</h:tt>.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="tableCell" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element tableCell
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A cell in a row of a table.</h:div><h:div class="description">tableCell
is a data container of the table and only occurs as a child of tableRow.
Normally it contains
simpleContent, but may also contain a single child element (which could itself have
complex or mixed content). However tableCell should NOT directly contain
multiple children of any sort or mixed content. (It is declared as mixed
content here to allow either text or element content, but not both.).
The metadata for tableCells must be declared in a tableHeader/tableHeaderCell
system</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="tableCell" id="el.tableCell"><xsd:annotation><xsd:documentation><h:div class="summary">A cell in a row of a table.</h:div><h:div class="description">tableCell
is a data container of the table and only occurs as a child of tableRow.
Normally it contains
simpleContent, but may also contain a single child element (which could itself have
complex or mixed content). However tableCell should NOT directly contain
multiple children of any sort or mixed content. (It is declared as mixed
content here to allow either text or element content, but not both.).
The metadata for tableCells must be declared in a tableHeader/tableHeaderCell
system</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="1"><xsd:any processContents="lax" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element tableContent
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Unmarked content of a table.</h:div><h:div class="description"><h:p>This only occurs as simpleContent or a tableContent elements.
It contains table/@rows * table/@columns items arranged rowwise
(i.e. columns is fastest
moving). Metadata for columns must be defined in tableHeader.
The items of the
table are ASCII strings. They can be separated by whitespace
or by a defined single character delimiter as in<h:tt>array</h:tt>. The
data must be rectangular and each implicit column must have consistent semantics.
It can be used to hold CSV-like data (indeed CSV data can be directly entered as
long as there are no quoted commas in which cas a different delimiter (or
the safer tableRowList) should be used. Unlike tableRowList or arrayList (both of which can hold ASCII
strings or XML elements, tableContent can only hold strings.</h:p></h:div><h:div class="example" href="table7.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="tableContent" id="el.tableContent"><xsd:annotation><xsd:documentation><h:div class="summary">Unmarked content of a table.</h:div><h:div class="description"><h:p>This only occurs as simpleContent or a tableContent elements.
It contains table/@rows * table/@columns items arranged rowwise
(i.e. columns is fastest
moving). Metadata for columns must be defined in tableHeader.
The items of the
table are ASCII strings. They can be separated by whitespace
or by a defined single character delimiter as in<h:tt>array</h:tt>. The
data must be rectangular and each implicit column must have consistent semantics.
It can be used to hold CSV-like data (indeed CSV data can be directly entered as
long as there are no quoted commas in which cas a different delimiter (or
the safer tableRowList) should be used. Unlike tableRowList or arrayList (both of which can hold ASCII
strings or XML elements, tableContent can only hold strings.</h:p></h:div><h:div class="example" href="table7.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:simpleContent><xsd:extension base="xsd:string"><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="delimiter"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:extension></xsd:simpleContent></xsd:complexType></xsd:element>
Element tcell
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A cell in a row of a table.</h:div><h:div class="description">tcell may either carry the header information
for a column OR be a dat container of the table. Normally it contains
simpleContent, but may also contain a single child element. It should
NOT contain multiple children of any sort.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:element name="tcell" id="el.tcell"><xsd:annotation><xsd:documentation><h:div class="summary">A cell in a row of a table.</h:div><h:div class="description">tcell may either carry the header information
for a column OR be a dat container of the table. Normally it contains
simpleContent, but may also contain a single child element. It should
NOT contain multiple children of any sort.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/></xsd:documentation></xsd:annotation><xsd:complexType mixed="true"><xsd:sequence minOccurs="1"><xsd:any processContents="lax" minOccurs="0"/></xsd:sequence><xsd:attributeGroup ref="units"/><xsd:attributeGroup ref="dataType"/><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element trow
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A row in a table.</h:div><h:div class="description">trow may either carry all the header information,
OR be a row of the table. In both cases it must contain tcells.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="trow" id="el.trow"><xsd:annotation><xsd:documentation><h:div class="summary">A row in a table.</h:div><h:div class="description">trow may either carry all the header information,
OR be a row of the table. In both cases it must contain tcells.</h:div><h:div class="example" href="table5.xml"/><h:div class="example" href="table6.xml"/><h:div class="example" href="tabler.xml"/></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="tcell" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="dataType"><xsd:annotation><xsd:documentation><h:div class="specific">Only required when in tableHeader.
This indicates that the objects in the cells of this row are
of the type given by this value (normally "title",
"units", "dictRef", "id").</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/></xsd:complexType></xsd:element>
Element unitTypeList
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A container for several unitType entries.</h:div><h:div class="description">Usually forms the complete unitTypes dictionary
(along with metadata). Note: unitTypes used to be held under unitList, but
this was complicated to implement and unitTypeList makes a clean separation.</h:div><h:div class="example" href="unitTypeList1.xml"/><h:div class="curation">2006-01-28. PMR. created.</h:div>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div>
<h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div>
<h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/>
Source
<xsd:element name="unitTypeList" id="el.unitTypeList"><xsd:annotation><xsd:documentation><h:div class="summary">A container for several unitType entries.</h:div><h:div class="description">Usually forms the complete unitTypes dictionary
(along with metadata). Note: unitTypes used to be held under unitList, but
this was complicated to implement and unitTypeList makes a clean separation.</h:div><h:div class="example" href="unitTypeList1.xml"/><h:div class="curation">2006-01-28. PMR. created.</h:div></xsd:documentation></xsd:annotation><xsd:complexType><xsd:sequence><xsd:element ref="metadataList" minOccurs="0" maxOccurs="unbounded"/><xsd:element ref="unitType" minOccurs="0" maxOccurs="unbounded"/></xsd:sequence><xsd:attributeGroup ref="title"/><xsd:attributeGroup ref="id"/><xsd:attributeGroup ref="convention"/><xsd:attributeGroup ref="dictRef"/><xsd:attributeGroup ref="namespace"/><xsd:attributeGroup ref="siNamespace"/><xsd:attributeGroup ref="dictionaryPrefix"/><xsd:attributeGroup ref="href"><xsd:annotation><xsd:documentation><h:div class="specific">Maps dictRef prefix to the location of a
dictionary. 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.</h:div></xsd:documentation></xsd:annotation></xsd:attributeGroup></xsd:complexType></xsd:element>
Simple Type idType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description"><h:p>This is not formally of type ID (an XML NAME which must start with a letter and contain only letters, digits and<h:tt>.-_:</h:tt>). It is recommended that IDs start with a letter, and contain no punctuation or whitespace. The function in XSLT will generate semantically void unique IDs.</h:p><h:p>It is difficult to ensure uniqueness when documents are merged. We suggest
namespacing IDs, perhaps using the containing elements as the base.
Thus<h:tt>mol3:a1</h:tt>could be a useful unique ID.
However this is still experimental.</h:p></h:div>
<xsd:simpleType name="idType" id="st.idType"><xsd:annotation><xsd:documentation><h:div class="summary">A unique ID for an element.</h:div><h:div class="description"><h:p>This is not formally of type ID (an XML NAME which must start with a letter and contain only letters, digits and<h:tt>.-_:</h:tt>). It is recommended that IDs start with a letter, and contain no punctuation or whitespace. The function in XSLT will generate semantically void unique IDs.</h:p><h:p>It is difficult to ensure uniqueness when documents are merged. We suggest
namespacing IDs, perhaps using the containing elements as the base.
Thus<h:tt>mol3:a1</h:tt>could be a useful unique ID.
However this is still experimental.</h:p></h:div></xsd:documentation></xsd:annotation><!-- <xsd:restriction base="xsd:QName"/>--><xsd:restriction base="xsd:string"><xsd:pattern value="[A-Za-z][A-Za-z0-9\.\-_]*"/></xsd:restriction></xsd:simpleType>
Simple Type refType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to an existing object.</h:div><h:div class="description">A reference to an existing element in the document.
The target of the ref attribute must exist. The test for validity will normally
occur in the element's _appinfo_. Any DOM Node created from this element will
normally be a reference 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.</h:div><h:div class="description">The semantic of reference are normally identical to
an idType (e.g. "a123b"). Howevere there are some cases where compound references
are required, such as "a123b:pq456". It is likely that this will be superseded at
by RDF or Xpointer, but as long as we have non-uniqueIds this is a problem</h:div>
<xsd:simpleType name="refType" id="st.refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an existing object.</h:div><h:div class="description">A reference to an existing element in the document.
The target of the ref attribute must exist. The test for validity will normally
occur in the element's _appinfo_. Any DOM Node created from this element will
normally be a reference 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.</h:div><h:div class="description">The semantic of reference are normally identical to
an idType (e.g. "a123b"). Howevere there are some cases where compound references
are required, such as "a123b:pq456". It is likely that this will be superseded at
by RDF or Xpointer, but as long as we have non-uniqueIds this is a problem</h: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>
Simple Type namespaceRefType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An XML QName with required prefix.</h:div><h:div class="description"><h:p>A string referencing a dictionary, units, convention or other metadata.</h:p><h:p>The purpose is to allow authors to extend the vocabulary through
their own namespaces without altering the schema.
The prefix is mandatory. This convention is only used within
CML and related languages; it is NOT a generic URI.</h:p></h:div><h:div class="example" href="namespaceRefType1.xml"/>
<xsd:simpleType name="namespaceRefType" id="st.namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">An XML QName with required prefix.</h:div><h:div class="description"><h:p>A string referencing a dictionary, units, convention or other metadata.</h:p><h:p>The purpose is to allow authors to extend the vocabulary through
their own namespaces without altering the schema.
The prefix is mandatory. This convention is only used within
CML and related languages; it is NOT a generic URI.</h:p></h:div><h:div class="example" href="namespaceRefType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:annotation><xsd:documentation><h:div class="description"><h:p>The namespace prefix must start with an alpha character
and can only contain alphanumeric and '_'. The suffix can
have characters from the XML ID specification
(alphanumeric, '_', '.' and '-'</h:p></h:div></xsd:documentation></xsd:annotation><xsd:pattern value="[A-Za-z][A-Za-z0-9_]*:[A-Za-z][A-Za-z0-9_\.\-]*"/></xsd:restriction></xsd:simpleType>
Simple Type nonNegativeAngleType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A non-signed angle.</h:div><h:div class="description">Re-used by _angle_. Note that we also provide
positiveAngleType (e.g. for cell angles) and torsionAngleType for _torsion_.</h:div><h:div class="example" href="nonNegativeAngleType.xml"/>
<xsd:simpleType name="nonNegativeAngleType" id="st.nonNegativeAngleType"><xsd:annotation><xsd:documentation><h:div class="summary">A non-signed angle.</h:div><h:div class="description">Re-used by _angle_. Note that we also provide
positiveAngleType (e.g. for cell angles) and torsionAngleType for _torsion_.</h:div><h:div class="example" href="nonNegativeAngleType.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="0.0"/><xsd:maxInclusive value="180.0"/></xsd:restriction></xsd:simpleType>
Simple Type atomRefs3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to three distinct existing atoms in order.</h:div><h:div class="example" href="atomRefs31.xml"/>
<xsd:simpleType name="angleUnitsType" id="st.angleUnitsType"><xsd:annotation><xsd:documentation><h:div class="summary">An enumeration of allowed angle units.</h:div><h:div class="description">May be obsolete.</h:div><!--
<h:div class="example">
<h:pre>
</pre.</h:div>
--></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="degrees"/><xsd:enumeration value="radians"/></xsd:restriction></xsd:simpleType>
Simple Type errorValueType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An estimate of the error in the value of a quantity.</h:div><h:div class="description">An observed or calculated estimate of the error in the value of a numeric quantity. It should be ignored for dataTypes such as URL, date or string. The statistical basis of the errorValueType is not defined - it could be a range, an estimated standard deviation, an observed standard error, etc. This information can be added through _errorBasisType_.</h:div><h:div class="example" href="scalar1.xml"/>
<xsd:simpleType name="errorValueType" id="st.errorValueType"><xsd:annotation><xsd:documentation><h:div class="summary">An estimate of the error in the value of a quantity.</h:div><h:div class="description">An observed or calculated estimate of the error in the value of a numeric quantity. It should be ignored for dataTypes such as URL, date or string. The statistical basis of the errorValueType is not defined - it could be a range, an estimated standard deviation, an observed standard error, etc. This information can be added through _errorBasisType_.</h:div><h:div class="example" href="scalar1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"/></xsd:simpleType>
Simple Type errorBasisType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The basis of an error value.</h:div><h:div class="description">Errors in values can be of several types and this simpleType
provides a small controlled vocabulary.</h:div><h:div class="example" href="scalar1.xml"/>
<xsd:simpleType name="errorBasisType" id="st.errorBasisType"><xsd:annotation><xsd:documentation><h:div class="summary">The basis of an error value.</h:div><h:div class="description">Errors in values can be of several types and this simpleType
provides a small controlled vocabulary.</h:div><h:div class="example" href="scalar1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><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><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type minType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The minimum INCLUSIVE value of a quantity.</h:div><h:div class="description"><h: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<h:tt>min</h:tt>and<h:tt>min</h:tt>attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of<h:tt>min</h:tt>is usually an observed
quantity (or calculated from observations). To restrict a value, the<h:tt>minExclusive</h:tt>type in a dictionary should be used.</h:p><h:p>The type of the minimum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</h:p></h:div><h:div class="example" href="maxType1.xml"/>
<xsd:simpleType name="minType" id="st.minType"><xsd:annotation><xsd:documentation><h:div class="summary">The minimum INCLUSIVE value of a quantity.</h:div><h:div class="description"><h: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<h:tt>min</h:tt>and<h:tt>min</h:tt>attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of<h:tt>min</h:tt>is usually an observed
quantity (or calculated from observations). To restrict a value, the<h:tt>minExclusive</h:tt>type in a dictionary should be used.</h:p><h:p>The type of the minimum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</h:p></h:div><h:div class="example" href="maxType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"/></xsd:simpleType>
Simple Type maxType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The maximum INCLUSIVE value of a quantity.</h:div><h:div class="description"><h: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<h:tt>min</h:tt>and<h:tt>max</h:tt>attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of<h:tt>max</h:tt>is usually an observed
quantity (or calculated from observations). To restrict a value, the<h:tt>maxExclusive</h:tt>type in a dictionary should be used.</h:p><h:p>The type of the maximum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</h:p></h:div><h:div class="example" href="maxType1.xml"/>
<xsd:simpleType name="maxType" id="st.maxType"><xsd:annotation><xsd:documentation><h:div class="summary">The maximum INCLUSIVE value of a quantity.</h:div><h:div class="description"><h: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<h:tt>min</h:tt>and<h:tt>max</h:tt>attributes can be used to give a range for the quantity.
The statistical basis of this range is not defined. The value of<h:tt>max</h:tt>is usually an observed
quantity (or calculated from observations). To restrict a value, the<h:tt>maxExclusive</h:tt>type in a dictionary should be used.</h:p><h:p>The type of the maximum is the same as the quantity to which it refers - numeric,
date and string are currently allowed</h:p></h:div><h:div class="example" href="maxType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"/></xsd:simpleType>
Simple Type dataTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">an enumerated type for all dataTypes in STM.</h:div><h:div class="description"><h:p><h:tt>dataTypeType</h: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.</h:p><h:p>It will often be used an an attribute on<h:a href="el.scalar">scalar</h:a>,<h:a href="el.array">array</h:a>or<h:a href="el.matrix">matrix</h:a>elements.</h:p></h:div><h:div class="description">Note: the attribute xsi:type might be used to enforce the type-checking but I haven't worked this through yet.</h:div><h:div class="example" href="dataTypeType1.xml"/>
<xsd:simpleType name="dataTypeType" id="st.dataTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">an enumerated type for all dataTypes in STM.</h:div><h:div class="description"><h:p><h:tt>dataTypeType</h: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.</h:p><h:p>It will often be used an an attribute on<h:a href="el.scalar">scalar</h:a>,<h:a href="el.array">array</h:a>or<h:a href="el.matrix">matrix</h:a>elements.</h:p></h:div><h:div class="description">Note: the attribute xsi:type might be used to enforce the type-checking but I haven't worked this through yet.</h:div><h:div class="example" href="dataTypeType1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><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"/><!-- CML types --><xsd:enumeration value="dataTypeType"/><xsd:enumeration value="namespaceRefType"/><xsd:enumeration value="unitsType"/></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type unitsType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Scientific units.</h:div><h:div class="description">These will be linked to dictionaries of
units with conversion information, using namespaced references
(e.g.<h:tt>si:m</h:tt>). Distinguish carefully from _unitType_
which is an element describing a type of a unit in a
_unitList_.</h:div><h:div class="example" href="unit2.xml"/>
<xsd:simpleType name="unitsType" id="st.unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Scientific units.</h:div><h:div class="description">These will be linked to dictionaries of
units with conversion information, using namespaced references
(e.g.<h:tt>si:m</h:tt>). Distinguish carefully from _unitType_
which is an element describing a type of a unit in a
_unitList_.</h:div><h:div class="example" href="unit2.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="namespaceRefType"/></xsd:simpleType>
Simple Type errorValueArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Array of error estimate values.</h:div><h:div class="description">An observed or calculated estimate of the error in the value of a numeric quantity. It should be ignored for dataTypes such as URL, date or string. The statistical basis of the errorValueType is not defined - it could be a range, an estimated standard deviation, an observed standard error, etc. This information can be added through _errorBasisType_.</h:div><h:div class="example" href="scalar1.xml"/>
<xsd:simpleType name="errorValueArrayType" id="st.errorValueArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of error estimate values.</h:div><h:div class="description">An observed or calculated estimate of the error in the value of a numeric quantity. It should be ignored for dataTypes such as URL, date or string. The statistical basis of the errorValueType is not defined - it could be a range, an estimated standard deviation, an observed standard error, etc. This information can be added through _errorBasisType_.</h:div><h:div class="example" href="scalar1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="errorValueType"/></xsd:simpleType>
Simple Type floatArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">OBSOLETE An array of floats.</h:div><h:div class="description">An array of floats or other real numbers.
Not used in STM Schema, but re-used by CML and other languages.</h:div><h:div class="example" href="floatArrayType1.xml"/>
<xsd:simpleType name="floatArrayType" id="st.floatArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">OBSOLETE An array of floats.</h:div><h:div class="description">An array of floats or other real numbers.
Not used in STM Schema, but re-used by CML and other languages.</h:div><h:div class="example" href="floatArrayType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="xsd:double"/></xsd:simpleType>
Simple Type delimiterType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A single non-whitespace character to separate components in arrays.</h:div><h:div class="description"><h:p>Some STMML elements (such as<h:a href="el.array">array</h: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.</h:p><h: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.</h:p><h: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.</h:p><h:p>At present there is a controlled pattern of characters selected so as not to collide with common usage in XML document</h:p></h:div><h:div class="example" href="delimiterType1.xml"><h:em>The values in the array are</h:em>"A", "B12", "" (empty string) and "D and E"<h:em>note the spaces</h:em></h:div>
<xsd:simpleType name="delimiterType" id="st.delimiterType"><xsd:annotation><xsd:documentation><h:div class="summary">A single non-whitespace character to separate components in arrays.</h:div><h:div class="description"><h:p>Some STMML elements (such as<h:a href="el.array">array</h: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.</h:p><h: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.</h:p><h: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.</h:p><h:p>At present there is a controlled pattern of characters selected so as not to collide with common usage in XML document</h:p></h:div><h:div class="example" href="delimiterType1.xml"><h:em>The values in the array are</h:em>"A", "B12", "" (empty string) and "D and E"<h:em>note the spaces</h:em></h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><!--<xsd:pattern value="[\!\$\%\^\*\@\~\;\#\,/\|]"/>--><xsd:pattern value="[!%\^\*@~;#,|/]"/></xsd:restriction></xsd:simpleType>
Simple Type sizeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The size of an array.</h:div><h:div class="description">The size of an array. Redundant, but serves as a check for processing software (useful if delimiters are used).</h:div>
<xsd:simpleType name="sizeType" id="st.sizeType"><xsd:annotation><xsd:documentation><h:div class="summary">The size of an array.</h:div><h:div class="description">The size of an array. Redundant, but serves as a check for processing software (useful if delimiters are used).</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:nonNegativeInteger"/></xsd:simpleType>
Simple Type matrixType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Allowed matrix types.</h:div><h:div class="description"><h:p>Many are square matrices. By default all elements must be included. For symmetric, antisymmetric and diagonal matrices some compression is possible by not reporting the identical or forced zero elements. These have their own subtypes, usually with UT or LT appended. Use these with caution as there is chance of confusion and you cannot rely on standard software to read these.</h:p><h:p>The matrix type fixes the order and semantics of the elements in the XML element but does not mandate any local syntax. Thus an application may insert newline characters after each row or use a <row> element.</h:p></h:div><h:div class="example" href="matrix1.xml"/>
<xsd:simpleType name="matrixType" id="st.matrixType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed matrix types.</h:div><h:div class="description"><h:p>Many are square matrices. By default all elements must be included. For symmetric, antisymmetric and diagonal matrices some compression is possible by not reporting the identical or forced zero elements. These have their own subtypes, usually with UT or LT appended. Use these with caution as there is chance of confusion and you cannot rely on standard software to read these.</h:p><h:p>The matrix type fixes the order and semantics of the elements in the XML element but does not mandate any local syntax. Thus an application may insert newline characters after each row or use a <row> element.</h:p></h:div><h:div class="example" href="matrix1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="rectangular"><xsd:annotation><xsd:documentation><h:div class="description">Rectangular with no semantic constraints and ordered rowwise (i.e. the column index runs fastest).<h:pre>1 2 3 4
0 3 5 6</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="square"><xsd:annotation><xsd:documentation><h:div class="description">Square with no semantic constraints.<h:pre>1 2 78
3 4 -1
-34 2 7</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareSymmetric"><xsd:annotation><xsd:documentation><h:div class="description">Square symmetric with all elements explicit.<h:pre>1 2 3
2 7 1
3 1 9</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareSymmetricLT"><xsd:annotation><xsd:documentation><h:div class="description">Square symmetric with the diagonal and lower triangle explicit and the upper triangle omitted. Rows are of length 1, 2, 3...<h:pre>1
2 7
3 1 9</h:pre>is equivalent to<h:pre>1 2 3
2 7 1
3 1 9</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareSymmetricUT"><xsd:annotation><xsd:documentation><h:div class="description">Square symmetric with the diagonal and upper triangle explicit. Rows are of length n, n-1, ... 2, 1<h:pre>1 7 9
2 -1
34</h:pre>is equivalent to<h:pre>1 7 9
7 2 -1
9 -1 34</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareAntisymmetric"><xsd:annotation><xsd:documentation><h:div class="description">Square antisymmetric with all elements explicit. The diagonal is necessarily zero.<h:pre>0 -2 3
2 0 1
-3 -1 0</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareAntisymmetricLT"><xsd:annotation><xsd:documentation><h:div class="description">Square symmetric with the lower triangle explicit and diagonal and upper triangle omitted. Rows are of length 1, 2,... n-1.<h:pre>-7
-9 1</h:pre>is equivalent to<h:pre>0 7 9
-7 0 -1
-9 1 0</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="squareAntisymmetricUT"><xsd:annotation><xsd:documentation><h:div class="description">Square symmetric with the upper triangle explicit and diagonal and lower triangle omitted. Rows are of length n-1, n-2,... 2,1.<h:pre>7 9
-1</h:pre>is equivalent to<h:pre>0 7 9
-7 0 -1
-9 1 0</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="diagonal"><xsd:annotation><xsd:documentation><h:div class="description">Symmetric. Elements are zero except on the diagonal. No compressed representation available (use<h:tt>array</h:tt>element).</h:div><h:pre>1 0 0
0 3 0
0 0 4</h:pre></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="upperTriangular"><xsd:annotation><xsd:documentation><h:div class="description">Square. Elements are zero below the diagonal<h:pre>1 2 3 4
0 3 5 6
0 0 4 8
0 0 0 2</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="upperTriangularUT"><xsd:annotation><xsd:documentation><h:div class="description">Square. Elements below the diagonal are zero and omitted, and rows are of length n, n-1, ... , 2, 1.<h:pre>1 2 3 4
3 5 6
4 8
2</h:pre>is equivalent to<h:pre>1 2 3 4
0 3 5 6
0 0 4 8
0 0 0 2</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="lowerTriangular"><xsd:annotation><xsd:documentation><h:div class="description">Square. Elements are zero above the diagonal<h:pre>1 0 0
7 3 0
9 2 4</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="lowerTriangularLT"><xsd:annotation><xsd:documentation><h:div class="description">Square. Elements above the diagonal are zero and omitted, and rows are of length 1, 2, ...n.<h:pre>1
3 7
9 2 3</h:pre>is equivalent to<h:pre>1 0 0
3 7 0
9 2 3</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="unit"><xsd:annotation><xsd:documentation><h:div class="description">Square. Diagonal elements are 1 and off-diagonal are zero.<h:pre>1 0 0
0 1 0
0 0 1</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="unitary"><xsd:annotation><xsd:documentation><h:div class="description">Square. When multiplied by its transpose gives the unit matrix.<h:pre>0 -1 0
1 0 0
0 0 1</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="rowEigenvectors"><xsd:annotation><xsd:documentation><h:div class="description">Square. Each row corresponds to an eigenvector of a square matrix. Elements are real. The length of the eigenvectors is undefined, i.e. they are not required to be normalised to 1.<h:pre>0 -1 0
1 0 0
0 0 1</h:pre></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="rotation22"><xsd:annotation><xsd:documentation><h:div class="description">The rotation is defined by the matrix premultiplyin a column vector (x, y) .<h:pre>0 -1
1 0</h:pre>produces (-y, x), i.e. a rotation of -90 degrees.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="rotationTranslation32"><xsd:annotation><xsd:documentation><h:div class="description">A third column defining the translation is added to a rotation22.<h:pre>0 -1 22
1 0 33</h:pre>produces (-y + 22, x + 33), i.e. a rotation of -90 degrees followed by a translation of (22, 33).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="homogeneous33"/><xsd:enumeration value="rotation33"/><xsd:enumeration value="rotationTranslation43"/><xsd:enumeration value="homogeneous44"/></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User-defined matrix-type.</h:div><h:div class="description">This definition must be by reference to a namespaced dictionary entry.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type metadataType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The name of the metadata.</h:div><h:div class="description">Metadata consists of name-value pairs (value is in the "content" attribute). The names are from a semi-restricted vocabulary, mainly Dublin Core. The content is unrestricted. The order of metadata has no implied semantics at present. Users can create their own metadata names using the namespaced prefix syntax (e.g. foo:institution). Ideally these names should be defined in an STMML dictionary.</h:div><h:div class="curation">2003-03-05: Added UNION to manage non-controlled name.</h:div>
<xsd:simpleType name="metadataType" id="st.metadataType"><xsd:annotation><xsd:documentation><h:div class="summary">The name of the metadata.</h:div><h:div class="description">Metadata consists of name-value pairs (value is in the "content" attribute). The names are from a semi-restricted vocabulary, mainly Dublin Core. The content is unrestricted. The order of metadata has no implied semantics at present. Users can create their own metadata names using the namespaced prefix syntax (e.g. foo:institution). Ideally these names should be defined in an STMML dictionary.</h:div><h:div class="curation">2003-03-05: Added UNION to manage non-controlled name.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="dc:coverage"><xsd:annotation><xsd:documentation><h:div class="definition">The extent or scope of the
content of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:description"><xsd:annotation><xsd:documentation><h:div class="definition">An account of the content of the
resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:identifier"><xsd:annotation><xsd:documentation><h:div class="definition">An unambiguous reference to the
resource within a given context.</h:div><h: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).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:format"><xsd:annotation><xsd:documentation><h:div class="definition">The physical or digital
manifestation of the resource.</h:div><h: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).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:relation"><xsd:annotation><xsd:documentation><h:div class="definition">A reference to a related
resource.</h:div><h:div class="description">Recommended best practice is to
reference the resource by means of a string or number
conforming to a formal identification system.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:rights"><xsd:annotation><xsd:documentation><h:div class="definition">Information about rights held in
and over the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:subject"><xsd:annotation><xsd:documentation><h:div class="definition">The topic of the content of the
resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:title"><xsd:annotation><xsd:documentation><h:div class="definition">A name given to the resource.</h:div><h:div class="description">Typically, a Title will be a name by
which the resource is formally known.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:type"><xsd:annotation><xsd:documentation><h:div class="definition">The nature or genre of the
content of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:contributor"><xsd:annotation><xsd:documentation><h:div class="definition">An entity responsible for making
contributions to the content of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:creator"><xsd:annotation><xsd:documentation><h:div class="definition">An entity primarily responsible
for making the content of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:publisher"><xsd:annotation><xsd:documentation><h:div class="definition">An entity responsible for making
the resource available.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:source"><xsd:annotation><xsd:documentation><h:div class="definition">A Reference to a resource from
which the present resource is derived.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:language"><xsd:annotation><xsd:documentation><h:div class="definition">A language of the intellectual
content of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="dc:date"><xsd:annotation><xsd:documentation><h:div class="definition">A date associated with an event
in the life cycle of the resource.</h:div><h: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.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="cmlm:safety"><xsd:annotation><xsd:documentation><h:div class="definition">Entry contains information
relating to chemical safety.</h:div><h:div class="description">Typically the content will be a
reference to a handbook, MSDS, threshhold or other
human-readable strin.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="cmlm:insilico"><xsd:annotation><xsd:documentation><h:div class="definition">Part or whole of the information
was computer-generated.</h:div><h:div class="description">Typically the content will be the
name of a method or a progra.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="cmlm:structure"><xsd:annotation><xsd:documentation><h:div class="definition">3D structure included.</h:div><h:div class="description">details include.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="cmlm:reaction"/><xsd:enumeration value="cmlm:identifier"/><xsd:enumeration value="other"/></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type stateType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">State of a substance or property.</h:div><h:div class="description">The state(s) of matter appropriate to a substance or property. It follows a partially controlled vocabulary. It can be extended through namespace codes to dictionaries.</h:div><h:div class="example" href="stateType1.xml"/>
<xsd:simpleType name="stateType" id="st.stateType"><xsd:annotation><xsd:documentation><h:div class="summary">State of a substance or property.</h:div><h:div class="description">The state(s) of matter appropriate to a substance or property. It follows a partially controlled vocabulary. It can be extended through namespace codes to dictionaries.</h:div><h:div class="example" href="stateType1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><!-- should be union with user-supplied --><xsd:enumeration value="aqueous"><xsd:annotation><xsd:documentation><h:div>An aqueous solutio.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="gas"><xsd:annotation><xsd:documentation><h:div>Gas or vapor. The default state for computation on isolated molecule.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="glass"><xsd:annotation><xsd:documentation><h:div>A glassy stat.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="liquid"><xsd:annotation><xsd:documentation><h:div>Normally pure liquid (use solution where appropriate.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="nematic"><xsd:annotation><xsd:documentation><h:div>The nematic phas.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="smectic"><xsd:annotation><xsd:documentation><h:div>The smectic phas.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="solid"><xsd:annotation><xsd:documentation><h:div>A soli.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="solidSolution"><xsd:annotation><xsd:documentation><h:div>A solid solutio.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="solution"><xsd:annotation><xsd:documentation><h:div>A (liquid) solutio.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type atomRefType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to an existing atom.</h:div><h:div class="example" href="atomRefType1.xml"/>
<xsd:simpleType name="atomRefType" id="st.atomRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an existing atom.</h:div><h:div class="example" href="atomRefType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="atomIDType"/></xsd:simpleType>
Simple Type atomIDType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An identifier for an atom.</h:div><h:div class="description"><h:p>Of the form prefix:suffix where prefix and suffix
are purely alphanumeric (with _ and -) and prefix
is optional. This is similar to XML IDs (and we promote
this as good practice for atomIDs. Other punctuation and
whitespace is forbidden, so IDs from (say) PDB files are
not satisfactory.</h:p><h:p>The prefix is intended to form a pseudo-namespace so that
atom IDs in different molecules may have identical suffixes.
It is also useful if the prefix is the ID for the molecule
(though this clearly has its limitation). Atom IDs should not
be typed as XML IDs since they may not validate.</h:p></h:div><h:div class="example" href="atomIDType1.xml"/>
<xsd:simpleType name="atomIDType" id="st.atomIDType"><xsd:annotation><xsd:documentation><h:div class="summary">An identifier for an atom.</h:div><h:div class="description"><h:p>Of the form prefix:suffix where prefix and suffix
are purely alphanumeric (with _ and -) and prefix
is optional. This is similar to XML IDs (and we promote
this as good practice for atomIDs. Other punctuation and
whitespace is forbidden, so IDs from (say) PDB files are
not satisfactory.</h:p><h:p>The prefix is intended to form a pseudo-namespace so that
atom IDs in different molecules may have identical suffixes.
It is also useful if the prefix is the ID for the molecule
(though this clearly has its limitation). Atom IDs should not
be typed as XML IDs since they may not validate.</h:p></h:div><h:div class="example" href="atomIDType1.xml"/></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-Za-z_][A-Za-z0-9_\-]*(:[A-Za-z0-9_\-]+)?"/></xsd:restriction></xsd:simpleType>
Simple Type atomRefArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of atomRefs.</h:div><h:div class="description">The atomRefs
cannot be schema- or schematron-validated. Instances of this type will
be used in array-style representation of bonds and atomParitys.
It can also be used for arrays of atomIDTypes such as in complex stereochemistry,
geometrical definitions, atom groupings, etc.</h:div><h:div class="example" href="atomRefArrayType1.xml"/>
<xsd:simpleType name="atomRefArrayType" id="st.atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of atomRefs.</h:div><h:div class="description">The atomRefs
cannot be schema- or schematron-validated. Instances of this type will
be used in array-style representation of bonds and atomParitys.
It can also be used for arrays of atomIDTypes such as in complex stereochemistry,
geometrical definitions, atom groupings, etc.</h:div><h:div class="example" href="atomRefArrayType1.xml"/></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:list itemType="atomIDType"/></xsd:simpleType>
Simple Type bondRefType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to an existing bond.</h:div><h:div class="general">A reference to a bond may be made by atoms (e.g. for multicentre or pi-bonds), electrons (for annotating reactions or describing electronic properties) or possibly other bonds (no examples yet). The semantics are relatively flexible.</h:div><h:div class="example" href="bond1.xml"/>
<xsd:simpleType name="bondRefType" id="st.bondRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an existing bond.</h:div><h:div class="general">A reference to a bond may be made by atoms (e.g. for multicentre or pi-bonds), electrons (for annotating reactions or describing electronic properties) or possibly other bonds (no examples yet). The semantics are relatively flexible.</h:div><h:div class="example" href="bond1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-Za-z0-9_\-]+(:[A-Za-z0-9_\-]+)?"/></xsd:restriction></xsd:simpleType>
Simple Type bondRefArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of references to bonds.</h:div><h:div class="description">The references cannot (yet)
cannot be schema- or schematron-validated. Instances of this type will
be used in array-style representation of electron counts, etc.
It can also be used for arrays of bondIDTypes such as in complex stereochemistry,
geometrical definitions, bond groupings, etc.</h:div>
<xsd:simpleType name="bondRefArrayType" id="st.bondRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of references to bonds.</h:div><h:div class="description">The references cannot (yet)
cannot be schema- or schematron-validated. Instances of this type will
be used in array-style representation of electron counts, etc.
It can also be used for arrays of bondIDTypes such as in complex stereochemistry,
geometrical definitions, bond groupings, etc.</h:div></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:list itemType="bondRefType"/></xsd:simpleType>
Simple Type positiveNumberType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A positive number.</h:div><h:div class="description">Note that we also provide<tt>nonNegativeNumber</tt>with inclusive zero. The maximum number is (quite large) since 'unbounded' is more difficult to implement.</h:div>
<xsd:simpleType name="positiveNumberType" id="st.positiveNumberType" xmlns="http://www.w3.org/1999/xhtml"><xsd:annotation><xsd:documentation><h:div class="summary">A positive number.</h:div><h:div class="description">Note that we also provide<tt>nonNegativeNumber</tt>with inclusive zero. The maximum number is (quite large) since 'unbounded' is more difficult to implement.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minExclusive value="0.0"/><xsd:maxInclusive value="1.0E+99"/></xsd:restriction></xsd:simpleType>
Simple Type stereoType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Bond stereochemistry as a string.</h:div><h:div class="description">This is purely conventional. There is no default value.
The emptyString attribute can be used to indicate a bond of
unknown or unspecified type. The interpretation of this is outside
the scope of CML-based algorithms. It may be accompanied by a<h:tt>convention</h:tt>attribute which links to a dictionary.</h:div><h:div class="example" href="bond1.xml"/>
<xsd:simpleType name="stereoType" id="st.stereoType"><xsd:annotation><xsd:documentation><h:div class="summary">Bond stereochemistry as a string.</h:div><h:div class="description">This is purely conventional. There is no default value.
The emptyString attribute can be used to indicate a bond of
unknown or unspecified type. The interpretation of this is outside
the scope of CML-based algorithms. It may be accompanied by a<h:tt>convention</h:tt>attribute which links to a dictionary.</h:div><h:div class="example" href="bond1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="C"><xsd:annotation><xsd:documentation><h:div class="summary">A cis bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="T"><xsd:annotation><xsd:documentation><h:div class="summary">A trans bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="W"><xsd:annotation><xsd:documentation><h:div class="summary">A wedge bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="H"><xsd:annotation><xsd:documentation><h:div class="summary">A hatch bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value=""><xsd:annotation><xsd:documentation><h:div class="summary">empty or missing.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType>
Simple Type atomRefs4Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to four distinct existing atoms in order.</h:div><h:div class="example" href="atomRefs41.xml"/>
<xsd:simpleType name="atomRefs2Type" id="st.atomRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to two distinct existing atoms in order.</h:div><h:div class="example" href="atomRefs21.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="atomIDType"/></xsd:simpleType><xsd:length value="2"/></xsd:restriction></xsd:simpleType>
Simple Type orderType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Bond order.</h:div><h:div class="description"><h:p>This is purely conventional and used
for bond/electron counting. There is no default value.
The emptyString attribute can be used to indicate a bond of
unknown or unspecified type. The interpretation of this is outside
the scope of CML-based algorithms. It may be accompanied by a<h:tt>convention</h:tt>attribute on the<h:tt>bond</h:tt>which links to a dictionary.
Example:<h:tt><bond convention="ccdc:9" atomRefs2="a1 a2"/></h:tt>could
represent a delocalised bond in the CCDC convention.</h:p></h:div>
<xsd:simpleType name="orderType" id="st.orderType"><xsd:annotation><xsd:documentation><h:div class="summary">Bond order.</h:div><h:div class="description"><h:p>This is purely conventional and used
for bond/electron counting. There is no default value.
The emptyString attribute can be used to indicate a bond of
unknown or unspecified type. The interpretation of this is outside
the scope of CML-based algorithms. It may be accompanied by a<h:tt>convention</h:tt>attribute on the<h:tt>bond</h:tt>which links to a dictionary.
Example:<h:tt><bond convention="ccdc:9" atomRefs2="a1 a2"/></h:tt>could
represent a delocalised bond in the CCDC convention.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="hbond"><xsd:annotation><xsd:documentation><h:div class="summary">Hydrogen bond.</h:div><h:div class="description">Carries no semantics but will normally be between a hydrogen atom and an element with lone pairs.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="partial01"><xsd:annotation><xsd:documentation><h:div class="summary">Partial bond.</h:div><h:div class="description">Can be used for a partial bond in a transition state, intermolecular interaction, etc. There is no numeric value associated and the bond order could be anywhere between 0 and single.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="S"><xsd:annotation><xsd:documentation><h:div class="summary">Single bond.</h:div><h:div class="description">synonymous with "1.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="1"><xsd:annotation><xsd:documentation><h:div class="summary">Single bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="partial12"><xsd:annotation><xsd:documentation><h:div class="summary">Intermediate between 1 and .</h:div><h:div class="description">Could be used for a transition state or a delocalised system.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="D"><xsd:annotation><xsd:documentation><h:div class="summary">Double bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="2"><xsd:annotation><xsd:documentation><h:div class="summary">Double bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="partial23"><xsd:annotation><xsd:documentation><h:div class="summary">Intermediate between 2 and .</h:div><h:div class="description">Could be used for a transition state or a delocalised system.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="T"><xsd:annotation><xsd:documentation><h:div class="summary">Triple bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="3"><xsd:annotation><xsd:documentation><h:div class="summary">Triple bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="A"><xsd:annotation><xsd:documentation><h:div class="summary">Aromatic bond.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type orderArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of bond orders.</h:div><h:div class="description">See order.</h:div>
<xsd:simpleType name="orderArrayType" id="st.orderArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of bond orders.</h:div><h:div class="description">See order.</h:div></xsd:documentation></xsd:annotation><xsd:list itemType="orderType"/></xsd:simpleType>
Simple Type vector3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A vector in 3-space.</h:div><h:div class="description">No constraints on magnitude (i.e. could be zero.</h:div><h:div class="example" href="vector31.xml"/>
<xsd:simpleType name="vector3Type" id="st.vector3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A vector in 3-space.</h:div><h:div class="description">No constraints on magnitude (i.e. could be zero.</h:div><h:div class="example" href="vector31.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:float"/></xsd:simpleType><xsd:length value="3"/></xsd:restriction></xsd:simpleType>
Simple Type matrix44Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A 4x4 transformation matrix</h:div><h:div class="description">This is the base for extending the transform3 element.</h:div>
<xsd:simpleType name="matrix44Type" id="st.matrix44Type"><xsd:annotation><xsd:documentation><h:div class="summary">A 4x4 transformation matrix</h:div><h:div class="description">This is the base for extending the transform3 element.</h:div></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="16"/></xsd:restriction></xsd:simpleType>
Simple Type formalChargeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The formal charge on an object.</h:div><h:div class="description">Used for electron-bookeeping. This has no relation to its calculated (fractional) charge or oxidation state.</h:div><h:div class="example" href="formalChargeType1.xml"/>
<xsd:simpleType name="formalChargeType" id="st.formalChargeType"><xsd:annotation><xsd:documentation><h:div class="summary">The formal charge on an object.</h:div><h:div class="description">Used for electron-bookeeping. This has no relation to its calculated (fractional) charge or oxidation state.</h:div><h:div class="example" href="formalChargeType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:integer"/></xsd:simpleType>
Simple Type formulaType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A concise representation for a molecular formula.</h:div><h:div class="description">This MUST adhere to a whitespaced syntax so that it is trivially
machine-parsable. Each element is followed by its count (which may be decimal),
and the string is optionally ended by a formal charge (of form d or -d, i.e. no '+')
NO brackets or other nesting is allowed.</h:div><h:div class="example" href="formulaType1.xml"/><h:div class="curation">2005-08-30: allowed decimal points</h:div>
<xsd:simpleType name="formulaType" id="st.formulaType"><xsd:annotation><xsd:documentation><h:div class="summary">A concise representation for a molecular formula.</h:div><h:div class="description">This MUST adhere to a whitespaced syntax so that it is trivially
machine-parsable. Each element is followed by its count (which may be decimal),
and the string is optionally ended by a formal charge (of form d or -d, i.e. no '+')
NO brackets or other nesting is allowed.</h:div><h:div class="example" href="formulaType1.xml"/><h:div class="curation">2005-08-30: allowed decimal points</h:div></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:restriction base="xsd:string"><!-- obsoleted
<xsd:pattern value="\s*([A-Z][a-z]?\s+([1-9][0-9]*(\.[0-9]*)?\s*))+(\s+[-|+]?[0-9]+)?\s*"/>--><!-- failed to support charge
<xsd:pattern value="\s*([A-Z][a-z]?\s+(([0-9]+(\.[0-9]*)?)|(\.[0-9]*))?\s*)+"/>--><xsd:pattern value="\s*([A-Z][a-z]?\s+(([0-9]+(\.[0-9]*)?)|(\.[0-9]*))?\s*)+(\s+[\-|+]?[0-9]+)?\s*"/></xsd:restriction></xsd:simpleType>
Simple Type torsionAngleType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of a torsion angle.</h:div>
<xsd:simpleType name="torsionAngleType" id="st.torsionAngleType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of a torsion angle.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="-360.0"/><xsd:maxInclusive value="360.0"/></xsd:restriction></xsd:simpleType>
Simple Type moleculeRefs2Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to two distinct existing molecules in order.</h:div><h:div class="summary">At present used for joining molecules or fragments(with join).</h:div><h:div class="curation">2006-11-24: PMR created</h:div><h:div class="example" href="moleculeRefs21.xml"/>
<xsd:simpleType name="moleculeRefs2Type" id="st.moleculeRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to two distinct existing molecules in order.</h:div><h:div class="summary">At present used for joining molecules or fragments(with join).</h:div><h:div class="curation">2006-11-24: PMR created</h:div><h:div class="example" href="moleculeRefs21.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="moleculeIDType"/></xsd:simpleType><xsd:length value="2"/></xsd:restriction></xsd:simpleType>
Simple Type chiralityType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div>
<xsd:simpleType name="chiralityType" id="st.chiralityType"><xsd:annotation><xsd:documentation><h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="enantiomer"/><xsd:enumeration value="racemate"/><xsd:enumeration value="unknown"/><xsd:enumeration value="other"/></xsd:restriction></xsd:simpleType>
Simple Type elementTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Allowed elementType values.</h:div><h:div class="description"><h:p>The periodic table (up to
element number 118. In addition the following strings are allowed:<h:ul><h:li><h:tt>Du</h:tt>. ("dummy") This does not correspond to a "real" atom and can
support a point in space or within a chemical graph.</h:li><h:li><h:tt>R</h:tt>. ("R-group") This indicates that an atom or group of atoms could be attached at this point.</h:li></h:ul></h:p></h:div><h:div class="example" href="elementTypeType1.xml"/>
Diagram
Type
union of(restriction of xsd:string, restriction of xsd:string)
<xsd:simpleType name="elementTypeType" id="st.elementTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed elementType values.</h:div><h:div class="description"><h:p>The periodic table (up to
element number 118. In addition the following strings are allowed:<h:ul><h:li><h:tt>Du</h:tt>. ("dummy") This does not correspond to a "real" atom and can
support a point in space or within a chemical graph.</h:li><h:li><h:tt>R</h:tt>. ("R-group") This indicates that an atom or group of atoms could be attached at this point.</h:li></h:ul></h:p></h:div><h:div class="example" href="elementTypeType1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="Ac"/><xsd:enumeration value="Al"/><xsd:enumeration value="Ag"/><xsd:enumeration value="Am"/><xsd:enumeration value="Ar"/><xsd:enumeration value="As"/><xsd:enumeration value="At"/><xsd:enumeration value="Au"/><xsd:enumeration value="B"/><xsd:enumeration value="Ba"/><xsd:enumeration value="Bh"/><xsd:enumeration value="Bi"/><xsd:enumeration value="Be"/><xsd:enumeration value="Bk"/><xsd:enumeration value="Br"/><xsd:enumeration value="C"/><xsd:enumeration value="Ca"/><xsd:enumeration value="Cd"/><xsd:enumeration value="Ce"/><xsd:enumeration value="Cf"/><xsd:enumeration value="Cl"/><xsd:enumeration value="Cm"/><xsd:enumeration value="Co"/><xsd:enumeration value="Cr"/><xsd:enumeration value="Cs"/><xsd:enumeration value="Cu"/><xsd:enumeration value="Db"/><xsd:enumeration value="Dy"/><xsd:enumeration value="Er"/><xsd:enumeration value="Es"/><xsd:enumeration value="Eu"/><xsd:enumeration value="F"/><xsd:enumeration value="Fe"/><xsd:enumeration value="Fm"/><xsd:enumeration value="Fr"/><xsd:enumeration value="Ga"/><xsd:enumeration value="Gd"/><xsd:enumeration value="Ge"/><xsd:enumeration value="H"><xsd:annotation><xsd:documentation><h:div class="summary">Any isotope of hydrogen.</h:div><h:div class="description"><h:p>There are no special element symbols for D and T which should use the<h:tt>isotope</h:tt>attribute.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="He"/><xsd:enumeration value="Hf"/><xsd:enumeration value="Hg"/><xsd:enumeration value="Ho"/><xsd:enumeration value="Hs"/><xsd:enumeration value="I"/><xsd:enumeration value="In"/><xsd:enumeration value="Ir"/><xsd:enumeration value="K"/><xsd:enumeration value="Kr"/><xsd:enumeration value="La"/><xsd:enumeration value="Li"/><xsd:enumeration value="Lr"/><xsd:enumeration value="Lu"/><xsd:enumeration value="Md"/><xsd:enumeration value="Mg"/><xsd:enumeration value="Mn"/><xsd:enumeration value="Mo"/><xsd:enumeration value="Mt"/><xsd:enumeration value="N"/><xsd:enumeration value="Na"/><xsd:enumeration value="Nb"/><xsd:enumeration value="Nd"/><xsd:enumeration value="Ne"/><xsd:enumeration value="Ni"/><xsd:enumeration value="No"/><xsd:enumeration value="Np"/><xsd:enumeration value="O"/><xsd:enumeration value="Os"/><xsd:enumeration value="P"/><xsd:enumeration value="Pa"/><xsd:enumeration value="Pb"/><xsd:enumeration value="Pd"/><xsd:enumeration value="Pm"/><xsd:enumeration value="Po"/><xsd:enumeration value="Pr"/><xsd:enumeration value="Pt"/><xsd:enumeration value="Pu"/><xsd:enumeration value="Ra"/><xsd:enumeration value="Rb"/><xsd:enumeration value="Re"/><xsd:enumeration value="Rf"/><xsd:enumeration value="Rh"/><xsd:enumeration value="Rn"/><xsd:enumeration value="Ru"/><xsd:enumeration value="S"/><xsd:enumeration value="Sb"/><xsd:enumeration value="Sc"/><xsd:enumeration value="Se"/><xsd:enumeration value="Sg"/><xsd:enumeration value="Si"/><xsd:enumeration value="Sm"/><xsd:enumeration value="Sn"/><xsd:enumeration value="Sr"/><xsd:enumeration value="Ta"/><xsd:enumeration value="Tb"/><xsd:enumeration value="Tc"/><xsd:enumeration value="Te"/><xsd:enumeration value="Th"/><xsd:enumeration value="Ti"/><xsd:enumeration value="Tl"/><xsd:enumeration value="Tm"/><xsd:enumeration value="U"/><xsd:enumeration value="Uun"/><xsd:enumeration value="Uuu"/><xsd:enumeration value="Uub"/><xsd:enumeration value="Uut"/><xsd:enumeration value="Uuq"/><xsd:enumeration value="Uup"/><xsd:enumeration value="Uuh"/><xsd:enumeration value="Uus"/><xsd:enumeration value="Uuo"/><xsd:enumeration value="V"/><xsd:enumeration value="W"/><xsd:enumeration value="Xe"/><xsd:enumeration value="Y"/><xsd:enumeration value="Yb"/><xsd:enumeration value="Zn"/><xsd:enumeration value="Zr"/><xsd:enumeration value="Dummy"/><xsd:enumeration value="Du"><xsd:annotation><xsd:documentation><h:div class="summary">A point or object with no chemical semantics.</h:div><h:div class="description"><h:p>Examples can be centroids, bond-midpoints, orienting "atoms" in small z-matrices.</h:p><h:p>Note "Dummy" has the same semantics but is now deprecated.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="R"><xsd:annotation><xsd:documentation><h:div class="summary">A point at which an atom or group might be attached.</h:div><h:div class="description"><h:p>Examples are abbreviated organic functional groups, Markush representations, polymers, unknown atoms, etc. Semantics may be determined by the<h:tt>role</h:tt>attribute on the atom.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:pattern value="[A-Za-z]+:[A-Za-z][A-Za-z0-9\-]+"/></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type hydrogenCountType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The total number of hydrogen atoms bonded to an object.</h:div><h:div class="description">The total number of hydrogen atoms bonded to an atom or contained in a molecule, whether explicitly included as atoms or not. It is an error to have hydrogen count less than the explicit hydrogen count. There is no default value and no assumptions about hydrogen Count can be made if it is not given. If hydrogenCount is given on every atom, then the values can be summed to give the total hydrogenCount for the (sub)molecule. Because of this hydrogenCount should not be used where hydrogen atoms bridge 2 or more atoms.</h:div><h:div class="example" href="atom1.xml"/>
<xsd:simpleType name="hydrogenCountType" id="st.hydrogenCountType"><xsd:annotation><xsd:documentation><h:div class="summary">The total number of hydrogen atoms bonded to an object.</h:div><h:div class="description">The total number of hydrogen atoms bonded to an atom or contained in a molecule, whether explicitly included as atoms or not. It is an error to have hydrogen count less than the explicit hydrogen count. There is no default value and no assumptions about hydrogen Count can be made if it is not given. If hydrogenCount is given on every atom, then the values can be summed to give the total hydrogenCount for the (sub)molecule. Because of this hydrogenCount should not be used where hydrogen atoms bridge 2 or more atoms.</h:div><h:div class="example" href="atom1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:nonNegativeInteger"/></xsd:simpleType>
Simple Type occupancyType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A floating point number between 0 and 1 inclusive</h:div><h:div class="description">Originally for crystallographic occupancy but re-usable
for fractional yield, etc.</h:div><h:div class="example" href="atom1.xml"/>
<xsd:simpleType name="occupancyType" id="st.occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">A floating point number between 0 and 1 inclusive</h:div><h:div class="description">Originally for crystallographic occupancy but re-usable
for fractional yield, etc.</h:div><h:div class="example" href="atom1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="0"/><xsd:maxInclusive value="1"/></xsd:restriction></xsd:simpleType>
Simple Type elementTypeArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of elementTypes.</h:div><h:div class="description">Instances of this type will be used in array-style representation of atoms.</h:div><h:div class="example" href="elementTypeArrayType1.xml"/>
<xsd:simpleType name="elementTypeArrayType" id="st.elementTypeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of elementTypes.</h:div><h:div class="description">Instances of this type will be used in array-style representation of atoms.</h:div><h:div class="example" href="elementTypeArrayType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="elementTypeType"/></xsd:simpleType>
Simple Type countArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Array of counts.</h:div><h:div class="description">Normally, but not always, integers. can be used with a number of elements</h:div><h:div class="curation">2005-11-01: PMR the combination of dataType and list does not work
with JUMBO5.0 - so for the meantime we have removed the restriction</h:div>
<xsd:simpleType name="countArrayType" id="st.countArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of counts.</h:div><h:div class="description">Normally, but not always, integers. can be used with a number of elements</h:div><h:div class="curation">2005-11-01: PMR the combination of dataType and list does not work
with JUMBO5.0 - so for the meantime we have removed the restriction</h:div></xsd:documentation></xsd:annotation><!-- <xsd:list itemType="countType"/> this is correct but my software doesn't process it--><xsd:list itemType="xsd:double"/><!-- removed by PMR
<xsd:restriction base="xsd:double">
<xsd:minExclusive value="0.0"/>
<xsd:maxInclusive value="1.0E+99"/>
</xsd:restriction>
--></xsd:simpleType>
Simple Type formalChargeArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Array of formalCharges.</h:div><h:div class="description">Used for electron-bookeeping. This has no relation to its calculated (fractional) charge or oxidation state.</h:div><h:div class="example" href="formalChargeType1.xml"/>
<xsd:simpleType name="formalChargeArrayType" id="st.formalChargeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of formalCharges.</h:div><h:div class="description">Used for electron-bookeeping. This has no relation to its calculated (fractional) charge or oxidation state.</h:div><h:div class="example" href="formalChargeType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="formalChargeType"/></xsd:simpleType>
Simple Type hydrogenCountArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">The total number of hydrogen atoms bonded to an atom or contained in a molecule, whether explicitly included as atoms or not. It is an error to have hydrogen count less than the explicit hydrogen count. There is no default value and no assumptions about hydrogen Count can be made if it is not given. If hydrogenCount is given on every atom, then the values can be summed to give the total hydrogenCount for the (sub)molecule. Because of this hydrogenCount should not be used where hydrogen atoms bridge 2 or more atoms.</h:div><h:div class="example" href="atom1.xml"/>
<xsd:simpleType name="hydrogenCountArrayType" id="st.hydrogenCountArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">The total number of hydrogen atoms bonded to an atom or contained in a molecule, whether explicitly included as atoms or not. It is an error to have hydrogen count less than the explicit hydrogen count. There is no default value and no assumptions about hydrogen Count can be made if it is not given. If hydrogenCount is given on every atom, then the values can be summed to give the total hydrogenCount for the (sub)molecule. Because of this hydrogenCount should not be used where hydrogen atoms bridge 2 or more atoms.</h:div><h:div class="example" href="atom1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="hydrogenCountType"/></xsd:simpleType>
Simple Type occupancyArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Array of atomic occupancies.</h:div><h:div class="description">Primarily for crystallography. Values outside 0-1 are not allowed.</h:div><h:div class="example" href="atom1.xml"/>
<xsd:simpleType name="occupancyArrayType" id="st.occupancyArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of atomic occupancies.</h:div><h:div class="description">Primarily for crystallography. Values outside 0-1 are not allowed.</h:div><h:div class="example" href="atom1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="occupancyType"/></xsd:simpleType>
Simple Type coordinateComponentArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of coordinateComponents for a single coordinate.</h:div><h:div class="description">An array of coordinateComponents for a single coordinate
where these all refer to an X-coordinate (NOT x,y,z).Instances of this type will be
used in array-style representation of 2-D or 3-D coordinates. Currently no machine
validation. Currently not used in STMML, but re-used by CML (see example).</h:div><h:div class="example" href="coordinateComponentArrayType1.xml"/>
<xsd:simpleType name="coordinateComponentArrayType" id="st.coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of coordinateComponents for a single coordinate.</h:div><h:div class="description">An array of coordinateComponents for a single coordinate
where these all refer to an X-coordinate (NOT x,y,z).Instances of this type will be
used in array-style representation of 2-D or 3-D coordinates. Currently no machine
validation. Currently not used in STMML, but re-used by CML (see example).</h:div><h:div class="example" href="coordinateComponentArrayType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="xsd:double"/></xsd:simpleType>
Simple Type actionOrderType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Describes whether child elements are sequential or parallel.</h:div><h:div class="description">There is no default.</h:div>
<xsd:simpleType id="st.actionOrderType" name="actionOrderType"><xsd:annotation><xsd:documentation><h:div class="summary">Describes whether child elements are sequential or parallel.</h:div><h:div class="description">There is no default.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="sequential"/><xsd:enumeration value="parallel"/></xsd:restriction></xsd:simpleType>
Simple Type alternativeTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div>
<xsd:simpleType id="st.alternativeTypeType" name="alternativeTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div></xsd:documentation></xsd:annotation><xsd:union><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:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type box3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A box in 3-space.</h:div><h:div class="description">Defined by 6 real numbers
(x1 y1 z1 x2 y2 z2). By default these are Cartesian coordinates (with units
specified elsewhere - responsibility of schema creator.) If there is a means
of specifying oblique axes (e.g. crystallographic cell) the box may be a
parallelipiped. The components are grouped in threes ans separated by a semicolon
to avoid problems of guessing the convention.</h:div><h:div class="example" href="box31.xml"/>
<xsd:simpleType name="box3Type" id="st.box3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A box in 3-space.</h:div><h:div class="description">Defined by 6 real numbers
(x1 y1 z1 x2 y2 z2). By default these are Cartesian coordinates (with units
specified elsewhere - responsibility of schema creator.) If there is a means
of specifying oblique axes (e.g. crystallographic cell) the box may be a
parallelipiped. The components are grouped in threes ans separated by a semicolon
to avoid problems of guessing the convention.</h:div><h:div class="example" href="box31.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="6"/></xsd:restriction></xsd:simpleType>
Simple Type cellParameterType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">enumerated type of cellParameter</h:div><h:div class="description"/><h:div class="example" href="cellParameterType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
enumeration
length
enumeration
angle
Source
<xsd:simpleType name="cellParameterType" id="st.cellParameterType"><xsd:annotation><xsd:documentation><h:div class="summary">enumerated type of cellParameter</h:div><h:div class="description"/><h:div class="example" href="cellParameterType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="length"/><xsd:enumeration value="angle"/></xsd:restriction></xsd:simpleType>
Simple Type complexType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A pair of floats representing a complex number.</h:div><h:div class="example" href="complex1.xml"/><h:div class="example" href="complex.bad.xml"><h:p>This example is schema-invalid as it has three floats</h:p></h:div>
<xsd:simpleType name="complexType" id="st.complexType"><xsd:annotation><xsd:documentation><h:div class="summary">A pair of floats representing a complex number.</h:div><h:div class="example" href="complex1.xml"/><h:div class="example" href="complex.bad.xml"><h:p>This example is schema-invalid as it has three floats</h:p></h:div></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="2"/></xsd:restriction></xsd:simpleType>
Simple Type coordinate2Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An x/y coordinate pair.</h:div><h:div class="description">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</h:div><h:div class="example" href="coordinate2Type1.xml"/>
<xsd:simpleType name="coordinate2Type" id="st.coordinate2Type"><xsd:annotation><xsd:documentation><h:div class="summary">An x/y coordinate pair.</h:div><h:div class="description">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</h:div><h:div class="example" href="coordinate2Type1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="2"/></xsd:restriction></xsd:simpleType>
Simple Type coordinate3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An x/y/z coordinate triple.</h:div><h:div class="description">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.</h:div><h:div class="example" href="coordinate3Type1.xml"/>
<xsd:simpleType name="coordinate3Type" id="st.coordinate3Type"><xsd:annotation><xsd:documentation><h:div class="summary">An x/y/z coordinate triple.</h:div><h:div class="description">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.</h:div><h:div class="example" href="coordinate3Type1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="3"/></xsd:restriction></xsd:simpleType>
Simple Type countType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A count multiplier for an object.</h:div><h:div class="description">Many elements represent objects which can occur an arbitrary number of times in a scientific context. Examples are<h:tt>action</h:tt>,<h:tt>object</h:tt>or<h:tt>molecule</h:tt>s.</h:div><h:div class="curation">2005-10-16. Changed to positiveNumerType.</h:div><h:div class="example" href="countType1.xml"/>
<xsd:simpleType name="countType" id="st.countType"><xsd:annotation><xsd:documentation><h:div class="summary">A count multiplier for an object.</h:div><h:div class="description">Many elements represent objects which can occur an arbitrary number of times in a scientific context. Examples are<h:tt>action</h:tt>,<h:tt>object</h:tt>or<h:tt>molecule</h:tt>s.</h:div><h:div class="curation">2005-10-16. Changed to positiveNumerType.</h:div><h:div class="example" href="countType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="positiveNumberType"/></xsd:simpleType>
Simple Type dictionaryPrefixType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A dictionaryPrefix</h:div><h:div class="description"><h:p>used to identify a dictionary, units, convention or other metadata.</h:p></h:div><h:div class="curation">2005-12-12: PMR. Added for use with dictionary</h:div>
<xsd:simpleType name="dictionaryPrefixType" id="st.dictionaryPrefixType"><xsd:annotation><xsd:documentation><h:div class="summary">A dictionaryPrefix</h:div><h:div class="description"><h:p>used to identify a dictionary, units, convention or other metadata.</h:p></h:div><!-- <h:div class="example" href="dictionaryPrefixType1.xml"></h:div>--><h:div class="curation">2005-12-12: PMR. Added for use with dictionary</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:annotation><xsd:documentation><h:div class="description"><h:p>The dictionary prefix must conform to XSD.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:pattern value="[A-Za-z][A-Za-z0-9_\.\-]*"/></xsd:restriction></xsd:simpleType>
Simple Type dimensionType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Allowed values for dimension Types in quantities.</h:div><h:div class="description"><h: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.</h:p><h:p>Used for constructing entries in a dictionary of units</h:p></h:div><h:div class="example" href="dimensionType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
enumeration
mass
enumeration
length
enumeration
time
enumeration
current
enumeration
amount
enumeration
luminosity
enumeration
temperature
enumeration
dimensionless
enumeration
angle
<h:div class="summary">An angl.</h:div><h:div class="description">(formally dimensionless, but useful to have units).</h:div>
<xsd:simpleType name="dimensionType" id="st.dimensionType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed values for dimension Types in quantities.</h:div><h:div class="description"><h: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.</h:p><h:p>Used for constructing entries in a dictionary of units</h:p></h:div><h:div class="example" href="dimensionType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="mass"/><xsd:enumeration value="length"/><xsd:enumeration value="time"/><xsd:enumeration value="current"/><xsd:enumeration value="amount"/><xsd:enumeration value="luminosity"/><xsd:enumeration value="temperature"/><xsd:enumeration value="dimensionless"/><xsd:enumeration value="angle"><xsd:annotation><xsd:documentation><h:div class="summary">An angl.</h:div><h:div class="description">(formally dimensionless, but useful to have units).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType>
Simple Type eigenOrientationType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Orientation of the eigenvector matrix.</h:div><h:div class="description"><h:p>Specifies whether the rows or columns of the (square) matrix
correspond to the eigenvectors. For example, in molecular orbitals
the vectors are normally represented as columns, and each column
would correspond to a different eigenvalue</h:p></h:div><h:div class="curation">2006-01-13: PMR. Created.</h:div>
<xsd:simpleType name="eigenOrientationType" id="st.eigenOrientationType"><xsd:annotation><xsd:documentation><h:div class="summary">Orientation of the eigenvector matrix.</h:div><h:div class="description"><h:p>Specifies whether the rows or columns of the (square) matrix
correspond to the eigenvectors. For example, in molecular orbitals
the vectors are normally represented as columns, and each column
would correspond to a different eigenvalue</h:p></h:div><h:div class="curation">2006-01-13: PMR. Created.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="columnVectors"><xsd:annotation><xsd:documentation><h:div class="summary">The columns are the eigenvectors.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="rowVectors"><xsd:annotation><xsd:documentation><h:div class="summary">The columns are the eigenvectors.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type formatType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div>
<xsd:simpleType id="st.formatType" name="formatType"><xsd:annotation><xsd:documentation><h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="1D"><xsd:annotation><xsd:documentation><h:div class="summary">one dimensional spectru.</h:div><h:div class="description">Data are represented by two _array_s, one representing the independent variable (e.g. wavelength, mass number) and the other the measured dependent variable (absorption, intensity, etc.). This can normally be plotted directly with the independent variable as the x-axis. The order of the points is not necessarily significant and may be increasing or decreasing.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="2Dsymm"><xsd:annotation><xsd:documentation><h:div class="summary">Two dimensional spectru.</h:div><h:div class="description">Data are represented by a single symmetric _matrix_ with both axes identical (i.e. the same independent variable). A typical example is a "2D 1HNMR spectrum". The dependent variable is represented by the matrix elements. This can normally be plotted as a square symmentric about a diagonal.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="2Dasymm"><xsd:annotation><xsd:documentation><h:div class="summary">Two dimensional spectrum with different axe.</h:div><h:div class="description">Data are represented by non-square _matrix_ with independent axes. A typical example is a "2D 1H 13C NMR spectrum". The dependent variable is represented by the matrix elements. .</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type ftType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div>
<xsd:simpleType id="st.ftType" name="ftType"><xsd:annotation><xsd:documentation><h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="raw"><xsd:annotation><xsd:documentation><h:div class="summary">Data are raw, so will normally require transforming.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="transformed"><xsd:annotation><xsd:documentation><h:div class="summary">Data have been transformed. This value indicates that an FT experiment and transformation have been performe.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="none"><xsd:annotation><xsd:documentation><h:div class="summary">This was not known to be an FT experiment. (It may have been, but the author or abstracter omitted to mention it).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type headType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The head linker in a polymeric repeat unit</h:div><h:div class="description"><h:p>A polymeric chain may be described by liniing the head of one repeat
unit to the tail or head of another. The head attribute indicates the atom
id (normally on an atom of elementType="R") which acts as the head</h:p></h:div><h:div class="curation">2006-05-20: PMR added</h:div><h:div class="example" href="headType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
pattern
[A-z][A-z0-9_]*
Source
<xsd:simpleType name="headType" id="st.headType"><xsd:annotation><xsd:documentation><h:div class="summary">The head linker in a polymeric repeat unit</h:div><h:div class="description"><h:p>A polymeric chain may be described by liniing the head of one repeat
unit to the tail or head of another. The head attribute indicates the atom
id (normally on an atom of elementType="R") which acts as the head</h:p></h:div><h:div class="curation">2006-05-20: PMR added</h:div><h:div class="example" href="headType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-z][A-z0-9_]*"/></xsd:restriction></xsd:simpleType>
Simple Type idArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of ids or idRefs.</h:div><h:div class="description">See idType.</h:div>
<xsd:simpleType name="idArrayType" id="st.idArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of ids or idRefs.</h:div><h:div class="description">See idType.</h:div></xsd:documentation></xsd:annotation><xsd:list itemType="idType"/></xsd:simpleType>
Simple Type inheritType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div>
Diagram
Type
restriction of xsd:string
Facets
enumeration
merge
<h:div class="summary">Values from this element will be merged.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will not conflict with the existing information. It is an error if there is a conflict.</h:div>
enumeration
replace
<h:div class="summary">Values from this element will replace existing information.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will replace the existing information.</h:div>
enumeration
delete
<h:div class="summary">Components of this element will de deleted if they exist.</h:div>
<xsd:simpleType id="st.inheritType" name="inheritType"><xsd:annotation><xsd:documentation><h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="merge"><xsd:annotation><xsd:documentation><h:div class="summary">Values from this element will be merged.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will not conflict with the existing information. It is an error if there is a conflict.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="replace"><xsd:annotation><xsd:documentation><h:div class="summary">Values from this element will replace existing information.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will replace the existing information.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="delete"><xsd:annotation><xsd:documentation><h:div class="summary">Components of this element will de deleted if they exist.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType>
Simple Type integerArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of integers.</h:div><h:div class="description">An array of integers; for re-use by other schemas. Not machine-validatable.</h:div><h:div class="example" href="integerArrayType1.xml"/>
Diagram
Type
list of xsd:integer
Source
<xsd:simpleType name="integerArrayType" id="st.integerArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of integers.</h:div><h:div class="description">An array of integers; for re-use by other schemas. Not machine-validatable.</h:div><h:div class="example" href="integerArrayType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="xsd:integer"/></xsd:simpleType>
Simple Type isotopeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The numeric representation of an isotope.</h:div><h:div class="description"><h:p>In core CML this represents a single number; either the
combined proton/neutron count or a more accurate estimate of the
nuclear mass. This is admittedly fuzzy, and requires a more complex
object (which can manage conventions, lists of isotopic masses, etc.)
See<h:a href="el.isotope">isotope</h:a>.</h:p><h:p>The default is "natural abundance" - whatever that can be interpreted
as.</h:p><h:p>Delta values (i.e. deviations from the most abundant istopic mass)
are never allowed.</h:p></h:div>
Diagram
Type
restriction of xsd:double
Facets
maxInclusive
99999999999.0
minInclusive
0.0
Source
<xsd:simpleType name="isotopeType" id="st.isotopeType"><xsd:annotation><xsd:documentation><h:div class="summary">The numeric representation of an isotope.</h:div><h:div class="description"><h:p>In core CML this represents a single number; either the
combined proton/neutron count or a more accurate estimate of the
nuclear mass. This is admittedly fuzzy, and requires a more complex
object (which can manage conventions, lists of isotopic masses, etc.)
See<h:a href="el.isotope">isotope</h:a>.</h:p><h:p>The default is "natural abundance" - whatever that can be interpreted
as.</h:p><h:p>Delta values (i.e. deviations from the most abundant istopic mass)
are never allowed.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="0.0"/><xsd:maxInclusive value="99999999999.0"/></xsd:restriction></xsd:simpleType>
Simple Type isotopicSpinType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A fractional representation of the spin of the nucleus.</h:div>
<xsd:simpleType name="isotopicSpinType" id="st.isotopicSpinType"><xsd:annotation><xsd:documentation><h:div class="summary">A fractional representation of the spin of the nucleus.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="\d{1,}(/\d)?"/></xsd:restriction></xsd:simpleType>
<xsd:simpleType name="latticeType" id="st.latticeType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed lattice types.</h:div><h:div class="description"/><h:div class="example" href="lattice3.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="primitive"/><xsd:enumeration value="full"/><xsd:enumeration value="aCentred"><xsd:annotation><xsd:documentation><h:div class="summary">lattice with A centering.</h:div><h:div class="description">A lattice which uses the translation operator {0, 0.5, 0.5}.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User-defined lattice-type.</h:div><h:div class="description">This definition must be by reference to a namespaced dictionary entry.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type line3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An unbounded line in 3-space.</h:div><h:div class="description">Defined by 6 real numbers, conventionally an arbitrary
point on the line and a vector3. There is no significance to the point
(i.e. it is not the "end of the line") and there are an infinite number of
ways of representing the line. DANGER. Line3 now uses the point3 and vector3 attributes
and the line3Type may be OBSOLETED.</h:div><h:div class="example" href="line31.xml"/>
<xsd:simpleType name="line3Type" id="st.line3Type"><xsd:annotation><xsd:documentation><h:div class="summary">An unbounded line in 3-space.</h:div><h:div class="description">Defined by 6 real numbers, conventionally an arbitrary
point on the line and a vector3. There is no significance to the point
(i.e. it is not the "end of the line") and there are an infinite number of
ways of representing the line. DANGER. Line3 now uses the point3 and vector3 attributes
and the line3Type may be OBSOLETED.</h:div><h:div class="example" href="line31.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="6"/></xsd:restriction></xsd:simpleType>
Simple Type linkTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of the link.</h:div>
Diagram
Type
restriction of xsd:string
Facets
enumeration
extended
<h:div class="summary">A container for locators.</h:div>
enumeration
locator
<h:div class="summary">A link to an element.</h:div>
<xsd:simpleType id="st.linkTypeType" name="linkTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the link.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="extended"><xsd:annotation><xsd:documentation><h:div class="summary">A container for locators.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="locator"><xsd:annotation><xsd:documentation><h:div class="summary">A link to an element.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="arc"><xsd:annotation><xsd:documentation><h:div class="summary">A labelled link.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType>
Simple Type lmType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">symbolic represention of l amd m.</h:div><h:div class="description">takes avlues of s, p, px, dxy, dx2y2, f, etc.</h:div>
<h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div>
<xsd:simpleType id="st.measurementType" name="measurementType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="transmittance"><xsd:annotation><xsd:documentation><h:div class="summary">Data are transmittance, so "peaks" are usually troughs.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="absorbance"><xsd:annotation><xsd:documentation><h:div class="summary">Data are absorbanc.</h:div><h:div class="description">so "peaks" are normally peaks.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type moleculeIDType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An identifier for an molecule.</h:div><h:div class="description"><h:p>Of the form prefix:suffix where prefix and suffix
are purely alphanumeric (with _ and -) and prefix
is optional. This is similar to XML IDs (and we promote
this as good practice for moleculeIDs. Other punctuation and
whitespace is forbidden, so IDs from (say) PDB files are
not satisfactory.</h:p><h:p>The prefix is intended to form a pseudo-namespace so that
molecule IDs in different molecules may have identical suffixes.
It is also useful if the prefix is the ID for the molecule
(though this clearly has its limitation). molecule IDs should not
be typed as XML IDs since they may not validate.</h:p></h:div><h:div class="curation">2006-11-24: PMR created.</h:div><h:div class="example" href="moleculeIDType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
pattern
[A-Za-z_][A-Za-z0-9_\-]*(:[A-Za-z0-9_\-]+)?
Source
<xsd:simpleType name="moleculeIDType" id="st.moleculeIDType"><xsd:annotation><xsd:documentation><h:div class="summary">An identifier for an molecule.</h:div><h:div class="description"><h:p>Of the form prefix:suffix where prefix and suffix
are purely alphanumeric (with _ and -) and prefix
is optional. This is similar to XML IDs (and we promote
this as good practice for moleculeIDs. Other punctuation and
whitespace is forbidden, so IDs from (say) PDB files are
not satisfactory.</h:p><h:p>The prefix is intended to form a pseudo-namespace so that
molecule IDs in different molecules may have identical suffixes.
It is also useful if the prefix is the ID for the molecule
(though this clearly has its limitation). molecule IDs should not
be typed as XML IDs since they may not validate.</h:p></h:div><h:div class="curation">2006-11-24: PMR created.</h:div><h:div class="example" href="moleculeIDType1.xml"/></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-Za-z_][A-Za-z0-9_\-]*(:[A-Za-z0-9_\-]+)?"/></xsd:restriction></xsd:simpleType>
Simple Type moleculeRefArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of moleculeRefs.</h:div><h:div class="description">Typical applications are the annotation of
peaks in chromatograms and mapping reactions. The context of the
id resolution is the childOrSibling concept.</h:div>
<xsd:simpleType name="moleculeRefArrayType" id="st.moleculeRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of moleculeRefs.</h:div><h:div class="description">Typical applications are the annotation of
peaks in chromatograms and mapping reactions. The context of the
id resolution is the childOrSibling concept.</h:div><!-- <h:div class="example" href="moleculeRefArrayType1.xml"></h:div>--></xsd:documentation><xsd:appinfo/></xsd:annotation><xsd:list itemType="moleculeRefType"/></xsd:simpleType>
Simple Type moleculeRefType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A reference to an existing molecule.</h:div>
<xsd:simpleType name="moleculeRefType" id="st.moleculeRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an existing molecule.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="idType"/></xsd:simpleType>
Simple Type namespaceArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of namespaceURIs with required protocol.</h:div><h:div class="description"><h:p>used to identify dictionaries, units, conventions or other metadata.</h:p></h:div><h:div class="curation">2005-12-17: PMR. Added for use with unitList</h:div>
<xsd:simpleType name="namespaceArrayType" id="st.namespaceArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of namespaceURIs with required protocol.</h:div><h:div class="description"><h:p>used to identify dictionaries, units, conventions or other metadata.</h:p></h:div><!-- <h:div class="example" href="namespaceRefType1.xml"></h:div>--><h:div class="curation">2005-12-17: PMR. Added for use with unitList</h:div></xsd:documentation></xsd:annotation><xsd:list itemType="namespaceType"/></xsd:simpleType>
Simple Type namespaceType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A namespaceURI with required protocol.</h:div><h:div class="description"><h:p>used to identify a dictionary, units, convention or other metadata.
Not yet confirmant with XSD</h:p></h:div><h:div class="example" href="namespaceRefType1.xml"/><h:div class="curation">2005-12-10: PMR. Added for use with dictionary</h:div>
<xsd:simpleType name="namespaceType" id="st.namespaceType"><xsd:annotation><xsd:documentation><h:div class="summary">A namespaceURI with required protocol.</h:div><h:div class="description"><h:p>used to identify a dictionary, units, convention or other metadata.
Not yet confirmant with XSD</h:p></h:div><h:div class="example" href="namespaceRefType1.xml"/><h:div class="curation">2005-12-10: PMR. Added for use with dictionary</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:annotation><xsd:documentation><h:div class="description"><h:p>The namespace prefix must start with a protocol.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:pattern value="http://[A-Za-z][A-Za-z0-9_\.\-]*(/[A-Za-z0-9_\.\-]+)+"/></xsd:restriction></xsd:simpleType>
Simple Type nonHydrogenCountType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The number of non-hydrogen atoms attached to an atom.</h:div><h:div class="description">Obsolete in core CML. Only useful in CML queries.</h:div>
Diagram
Type
xsd:nonNegativeInteger
Source
<xsd:simpleType name="nonHydrogenCountType" id="st.nonHydrogenCountType"><xsd:annotation><xsd:documentation><h:div class="summary">The number of non-hydrogen atoms attached to an atom.</h:div><h:div class="description">Obsolete in core CML. Only useful in CML queries.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:nonNegativeInteger"/></xsd:simpleType>
Simple Type nonNegativeNumberType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="description">A nonNegative number.</h:div><h:div class="description">Note that we also provide positiveNumber to avoid inclusive zero. The maximum number is 1.0E+999 since 'unbounded' is more difficult to implement. This is greater than Eddington's estimate of the number of particles in the universe so it should work for most people.</h:div>
Diagram
Type
restriction of xsd:double
Facets
maxInclusive
1.0E+99
minInclusive
0.0
Source
<xsd:simpleType name="nonNegativeNumberType" id="st.nonNegativeNumberType"><xsd:annotation><xsd:documentation><h:div class="description">A nonNegative number.</h:div><h:div class="description">Note that we also provide positiveNumber to avoid inclusive zero. The maximum number is 1.0E+999 since 'unbounded' is more difficult to implement. This is greater than Eddington's estimate of the number of particles in the universe so it should work for most people.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="0.0"/><xsd:maxInclusive value="1.0E+99"/></xsd:restriction></xsd:simpleType>
Simple Type peakMultiplicityType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Multiplicity of a peak.</h:div><h:div class="description">Uses a semi-controlled vocabulary.</h:div>
<xsd:simpleType id="st.peakMultiplicityType" name="peakMultiplicityType"><xsd:annotation><xsd:documentation><h:div class="summary">Multiplicity of a peak.</h:div><h:div class="description">Uses a semi-controlled vocabulary.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="singlet"><xsd:annotation><xsd:documentation><h:div class="summary">A single maximum within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="doublet"><xsd:annotation><xsd:documentation><h:div class="summary">Two maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="triplet"><xsd:annotation><xsd:documentation><h:div class="summary">Three maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="quartet"><xsd:annotation><xsd:documentation><h:div class="summary">Four maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="quintet"><xsd:annotation><xsd:documentation><h:div class="summary">Five maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="sextuplet"><xsd:annotation><xsd:documentation><h:div class="summary">Six maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="multiplet"><xsd:annotation><xsd:documentation><h:div class="summary">Several maxima (not necessarily equal) within the peak rang.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div>User contributed vocabulary of type foo:ba.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type peakShapeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Shape of a peak.</h:div><h:div class="description">Semi-controlled vocabulary such as
broad or sharp.</h:div>
<xsd:simpleType id="st.peakShapeType" name="peakShapeType"><xsd:annotation><xsd:documentation><h:div class="summary">Shape of a peak.</h:div><h:div class="description">Semi-controlled vocabulary such as
broad or sharp.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="sharp"><xsd:annotation><xsd:documentation><h:div class="summary">A sharp peak.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="broad"><xsd:annotation><xsd:documentation><h:div class="summary">A broad peak.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="shoulder"><xsd:annotation><xsd:documentation><h:div class="summary">A brodening of a peak suggesting the presence of a smaller incompletely resolved component.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User contributed vocabulary of type foo:bar.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type peakStructureTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">type of a peakStructure.</h:div><h:div class="description">Semi-controlled vocabulary such as
coupling or splitting.</h:div>
<xsd:simpleType id="st.peakStructureTypeType" name="peakStructureTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">type of a peakStructure.</h:div><h:div class="description">Semi-controlled vocabulary such as
coupling or splitting.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="coupling"><xsd:annotation><xsd:documentation><h:div class="summary">A coupling such as in NMR.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="splitting"><xsd:annotation><xsd:documentation><h:div class="summary">A splitting such as in NMR.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User contributed vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type peakWidthType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The width of a peak.</h:div><h:div class="description">At present we allow a peakWidth to be positive
or exactly zero (to signal that the peak should not be integrated).</h:div>
Diagram
Type
restriction of xsd:double
Facets
maxInclusive
1.0E+99
minInclusive
0.0
Source
<xsd:simpleType name="peakWidthType" id="st.peakWidthType"><xsd:annotation><xsd:documentation><h:div class="summary">The width of a peak.</h:div><h:div class="description">At present we allow a peakWidth to be positive
or exactly zero (to signal that the peak should not be integrated).</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minInclusive value="0.0"/><xsd:maxInclusive value="1.0E+99"/></xsd:restriction></xsd:simpleType>
Simple Type plane3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An unbounded plane in 3-space.</h:div><h:div class="description">Defined by 4 real numbers, conventionally a vector3
normal to the plane and a signed scalar representing the distance to the origin.
The vector must not be of zero length (and need not be normalized.</h:div><h:div class="example" href="plane31.xml"><h:p>The first three numbers are the vector, followed by the distance</h:p></h:div>
<xsd:simpleType name="plane3Type" id="st.plane3Type"><xsd:annotation><xsd:documentation><h:div class="summary">An unbounded plane in 3-space.</h:div><h:div class="description">Defined by 4 real numbers, conventionally a vector3
normal to the plane and a signed scalar representing the distance to the origin.
The vector must not be of zero length (and need not be normalized.</h:div><h:div class="example" href="plane31.xml"><h:p>The first three numbers are the vector, followed by the distance</h:p></h:div></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="4"/></xsd:restriction></xsd:simpleType>
Simple Type point3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A point in 3-space.</h:div><h:div class="description">The 3 components can have any signed value.</h:div><h:div class="example" href="point31.xml"/>
<xsd:simpleType name="point3Type" id="st.point3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A point in 3-space.</h:div><h:div class="description">The 3 components can have any signed value.</h:div><h:div class="example" href="point31.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="3"/></xsd:restriction></xsd:simpleType>
Simple Type positiveAngleType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A non-signed angle such as a cell angle.</h:div><h:div class="description">Re-used by _crystal_. Note that we also provide
nonNegativeAngleType (e.g. for bond angles).</h:div><h:div class="example" href="positiveAngleType.xml"/>
Diagram
Type
restriction of xsd:double
Facets
maxInclusive
180.0
minExclusive
0.0
Source
<xsd:simpleType name="positiveAngleType" id="st.positiveAngleType"><xsd:annotation><xsd:documentation><h:div class="summary">A non-signed angle such as a cell angle.</h:div><h:div class="description">Re-used by _crystal_. Note that we also provide
nonNegativeAngleType (e.g. for bond angles).</h:div><h:div class="example" href="positiveAngleType.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:double"><xsd:minExclusive value="0.0"/><xsd:maxInclusive value="180.0"/></xsd:restriction></xsd:simpleType>
Simple Type reactionFormatType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The format of the reaction.</h:div><h:div><h:p>This is provided for machine-understanding of the format of the reaction steps and components.</h:p><h:p>Semantics are semi-controlled.</h:p></h:div>
<xsd:simpleType name="reactionFormatType" id="st.reactionFormatType"><xsd:annotation><xsd:documentation><h:div class="summary">The format of the reaction.</h:div><h:div><h:p>This is provided for machine-understanding of the format of the reaction steps and components.</h:p><h:p>Semantics are semi-controlled.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="reactantProduct"><xsd:annotation><xsd:documentation><h:div><h:p>The commonest representation with reactantList and productList.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="cmlSnap"><xsd:annotation><xsd:documentation><h:div><h:p>A list of molecules representing snap shots on a reaction pathway.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type reactionRoleType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The role of the reaction within a reactionList.</h:div><h:div class="description">Semantics are semi-controlled.</h:div>
<xsd:simpleType name="reactionRoleType" id="st.reactionRoleType"><xsd:annotation><xsd:documentation><h:div class="summary">The role of the reaction within a reactionList.</h:div><h:div class="description">Semantics are semi-controlled.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="complete"><xsd:annotation><xsd:documentation><h:div><h:p>On reactionList signifies that the children are the complete description of the reaction.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="overall"><xsd:annotation><xsd:documentation><h:div><h:p>The overall reaction in a multi-step reaction. Normally this would be the first reaction in a reactionList and the individual steps are held in a following sibling reactionList.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="rateDeterminingStep"><xsd:annotation><xsd:documentation><h:div><h:p>The rate-determining step in a multi-step reaction. This implies also that the reaction has a role of step.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="step"><xsd:annotation><xsd:documentation><h:div><h:p>A step in a multi-step reaction. This reaction will normally be a child of reactionList.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="steps"><xsd:annotation><xsd:documentation><h:div><h:p>a reactionList containing steps</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div><h:p>Examples could be "myDict:step1", "foo:chainPropagation", etc.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type reactionStepListTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div>
<xsd:simpleType id="st.reactionStepListTypeType" name="reactionStepListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="unknown"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the steps is unknown.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="consecutive"><xsd:annotation><xsd:documentation><h:div class="summary">The reaction proceeds through the steps in the order given.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="choice"><xsd:annotation><xsd:documentation><h:div class="summary">The reaction may proceed through either (or possibly both) of the contained reactions or reactionScheme, but it may not be known which.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="simultaneous"><xsd:annotation><xsd:documentation><h:div class="summary">The two or more independent reaction/List children proceed independently.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type reactionTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The semantic type of the reaction.</h:div><h:div><h:p>This is provided for machine-understanding of the topology or logic of the reaction steps and components (i.e. not for a general classification for which<h:tt>label</h:tt>is more appropriate.)</h:p><h:p>Semantics are semi-controlled. Some terms are appropriate to multistep reactions, and can be used with or without explicit steps.</h:p></h:div>
<xsd:simpleType name="reactionTypeType" id="st.reactionTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The semantic type of the reaction.</h:div><h:div><h:p>This is provided for machine-understanding of the topology or logic of the reaction steps and components (i.e. not for a general classification for which<h:tt>label</h:tt>is more appropriate.)</h:p><h:p>Semantics are semi-controlled. Some terms are appropriate to multistep reactions, and can be used with or without explicit steps.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="chainReaction"><xsd:annotation><xsd:documentation><h:div><h:p>A reaction in which one or more reactive reaction intermediates (frequently radicals) are continuously regenerated, usually through a repetitive cycle of elementary steps (the 'propagation step') (IUPAC GoldBook).</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="initiation"><xsd:annotation><xsd:documentation><h:div><h:p>A reaction or process generating free radicals (or some other reactive
reaction intermediates) which then induce a chain reaction. For example,
in the chlorination of alkanes by a radical mechanism the initiation step is
the dissociation of molecular chlorine.
IUPAC Compendium of Chemical Terminology 2nd Edition (1997).</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="termination"><xsd:annotation><xsd:documentation><h:div><h:p>The steps in a chain reaction in which reactive intermediates are destroyed
or rendered inactive, thus ending the chain.
IUPAC Compendium of Chemical Terminology 2nd Edition (1997)
.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="reversible"><xsd:annotation><xsd:documentation><h:div><h:p>A reaction which can proceed in the forward direction as readily as in the reverse direction (IUPAC GoldBook).</h:p></h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type relatedEntryTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div>
<xsd:simpleType id="st.relatedEntryTypeType" name="relatedEntryTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><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:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type repeatType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">instruction to create repeat of the object.</h:div><h:div class="description">The attribute contains an index, its start value
(normally 1) and its end value as in "i 3 10" which would make 8 repeat
of the object. In selected attribute values the string _i_ acts as a macro and
would be replaced by the value of i. EXPERIMENTAL. It can also have variables
as the values.</h:div><h:div class="curation">2006-05-20: PMR added.</h:div><h:div class="example" href="repeatType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
pattern
[A-z]+ [A-z0-9_\-\+]+ [A-z0-9_\-\+]+
Source
<xsd:simpleType name="repeatType" id="st.repeatType"><xsd:annotation><xsd:documentation><h:div class="summary">instruction to create repeat of the object.</h:div><h:div class="description">The attribute contains an index, its start value
(normally 1) and its end value as in "i 3 10" which would make 8 repeat
of the object. In selected attribute values the string _i_ acts as a macro and
would be replaced by the value of i. EXPERIMENTAL. It can also have variables
as the values.</h:div><h:div class="curation">2006-05-20: PMR added.</h:div><h:div class="example" href="repeatType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-z]+ [A-z0-9_\-\+]+ [A-z0-9_\-\+]+"/></xsd:restriction></xsd:simpleType>
Simple Type schemeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div>
<xsd:simpleType id="st.schemeType" name="schemeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="unknown"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the steps is unknow.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="sequence"><xsd:annotation><xsd:documentation><h:div class="summary">The reaction proceeds through the steps in the order give.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="choice"><xsd:annotation><xsd:documentation><h:div class="summary">The reaction may proceed through either of the contained reactions or reactionScheme.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="and"><xsd:annotation><xsd:documentation><h:div class="summary">The two or more independent reaction/List children proceed independently. This can be extended to synthetic chemistry where two parts of the synthesis are conducted in parallel.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type shapeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Allowed shapes of arrayList.</h:div><h:div class="description"><h:p>Rectangular, triangular or irregular.</h:p></h:div><h:div class="example" href="arrayList1.xml"/>
<xsd:simpleType name="shapeType" id="st.shapeType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed shapes of arrayList.</h:div><h:div class="description"><h:p>Rectangular, triangular or irregular.</h:p></h:div><h:div class="example" href="arrayList1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="rectangular"><xsd:annotation><xsd:documentation><h:div class="description">Rectangular.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="triangularDecreasing."><xsd:annotation><xsd:documentation><h:div class="description">Triangular decreasing in size from ncols to 1.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="triangularIncreasing."><xsd:annotation><xsd:documentation><h:div class="description">Triangular increasing in size from 1 to ncols.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="irregular"><xsd:annotation><xsd:documentation><h:div class="description">Irregular shape.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User-defined arrayList-type.</h:div><h:div class="description">This definition must be by reference to a namespaced dictionary entry.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type spaceType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Signifies real or reciprocal space.</h:div><h:div class="description">Likely to be used on types such as lattice, plane, point.</h:div><h:div class="example" href="space1.xml"/>
<xsd:simpleType name="spaceType" id="st.spaceType"><xsd:annotation><xsd:documentation><h:div class="summary">Signifies real or reciprocal space.</h:div><h:div class="description">Likely to be used on types such as lattice, plane, point.</h:div><h:div class="example" href="space1.xml"/></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="real"/><xsd:enumeration value="k-space"><xsd:annotation><xsd:documentation><h:div class="description">A synonym for reciprocal.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="Fourier"><xsd:annotation><xsd:documentation><h:div class="description">A synonym for reciprocal.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="reciprocal"><xsd:annotation><xsd:documentation><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User-defined space-type.</h:div><h:div class="description">No obvious possibilities, but who know.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type spectrumTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The type of the spectrum.</h:div>
<xsd:simpleType id="st.spectrumTypeType" name="spectrumTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the spectrum.</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="infrared"><xsd:annotation><xsd:documentation><h:div class="summary">An infrared spectrum.</h:div><h:div class="description">The measurement should denote transmittance or absorbanc.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="massSpectrum"><xsd:annotation><xsd:documentation><h:div class="summary">A "simple" mass spectrum.</h:div><h:div class="description">This excludes experiments such as GC/MS, MS/MS, etc. though these could be constructed out of individual spectra with some care. The spectrum may be continuous (<h:tt>data</h:tt>or a<h:tt>peakList</h:tt>).</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="NMR"><xsd:annotation><xsd:documentation><h:div class="summary">An NMR spectrum.</h:div><h:div class="description">This can include any experiment which creates a "1D" or "2D" data array. The symmetry of the spectrum can be specified but the details of the NMR experiment (COSY, NOESY, etc.) are not part of CMLSpect. They can be described though the normal<h:tt>dictRef</h:tt>mechanism.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="UV/VIS"><xsd:annotation><xsd:documentation><h:div class="summary">A spectrum somewhere in the UV VIS region of the spectrum.</h:div><h:div class="description">The measurement should denote transmittance or absorbance.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"/></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type sphere3Type
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">A sphere in 3-space.</h:div><h:div class="description">Defined by 4 real numbers, conventionally a point3 at
the centre of the sphere and a nonNegative scalar for the radius.</h:div><h:div class="example" href="sphere31.xml"/>
<xsd:simpleType name="sphere3Type" id="st.sphere3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A sphere in 3-space.</h:div><h:div class="description">Defined by 4 real numbers, conventionally a point3 at
the centre of the sphere and a nonNegative scalar for the radius.</h:div><h:div class="example" href="sphere31.xml"/></xsd:documentation></xsd:annotation><xsd:restriction><xsd:simpleType><xsd:list itemType="xsd:double"/></xsd:simpleType><xsd:length value="4"/></xsd:restriction></xsd:simpleType>
Simple Type stringArrayType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">An array of strings, separated by whitespace.</h:div><h:div class="description">An array of strings, separated by whitespace. If the strings have embedded whitespace or may be empty (zero-length), a non-whitespace single-character delimiter must be used. At present no machine validation</h:div><h:div class="example" href="stringArrayType1.xml"/>
Diagram
Type
list of xsd:string
Source
<xsd:simpleType name="stringArrayType" id="st.stringArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of strings, separated by whitespace.</h:div><h:div class="description">An array of strings, separated by whitespace. If the strings have embedded whitespace or may be empty (zero-length), a non-whitespace single-character delimiter must be used. At present no machine validation</h:div><h:div class="example" href="stringArrayType1.xml"/></xsd:documentation></xsd:annotation><xsd:list itemType="xsd:string"/></xsd:simpleType>
Simple Type substanceListTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div>
<xsd:simpleType id="st.substanceListTypeType" name="substanceListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="solution"/><xsd:enumeration value="mixture"/><xsd:enumeration value="other"/></xsd:restriction></xsd:simpleType>
<xsd:simpleType name="tableTypeType" id="st.tableTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Allowed types of table.</h:div><h:div class="description"><h:p>rowBased, arrayBased, contentBased.</h:p></h:div><h:div class="example" href="arrayList1.xml"/><h:div class="curation">2006-11-03: formlized 3 table types</h:div></xsd:documentation></xsd:annotation><xsd:union><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="rowBased"><xsd:annotation><xsd:documentation><h:div class="description">rowBased.</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="arrayBased"><xsd:annotation><xsd:documentation><h:div class="description">Based on child arrayList containing arrays or lists</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="contentBased"><xsd:annotation><xsd:documentation><h:div class="description">child tableContent</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType><xsd:simpleType><xsd:restriction base="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">User-defined table-type.</h:div><h:div class="description">This definition must be by reference to a namespaced dictionary entry.</h:div></xsd:documentation></xsd:annotation></xsd:restriction></xsd:simpleType></xsd:union></xsd:simpleType>
Simple Type tailType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The tail linker in a polymeric repeat unit</h:div><h:div class="description"><h:p>A polymeric chain may be described by liniing the tail of one repeat
unit to the head or tail of another. The tail attribute indicates the atom
id (normally on an atom of elementType="R") which acts as the tail</h:p></h:div><h:div class="curation">2006-05-20: PMR added</h:div><h:div class="example" href="tailType1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
pattern
[A-z][A-z0-9_]*
Source
<xsd:simpleType name="tailType" id="st.tailType"><xsd:annotation><xsd:documentation><h:div class="summary">The tail linker in a polymeric repeat unit</h:div><h:div class="description"><h:p>A polymeric chain may be described by liniing the tail of one repeat
unit to the head or tail of another. The tail attribute indicates the atom
id (normally on an atom of elementType="R") which acts as the tail</h:p></h:div><h:div class="curation">2006-05-20: PMR added</h:div><h:div class="example" href="tailType1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[A-z][A-z0-9_]*"/></xsd:restriction></xsd:simpleType>
Simple Type unitListTypeType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Type of unitList.</h:div><h:div class="description">Required to differentiate between the two types of
unitList (units and unitTypes)</h:div>
Diagram
Type
restriction of xsd:string
Facets
enumeration
unit
<h:div class="description">child elements are unit</h:div>
enumeration
unitType
<h:div class="description">child elements are unitType</h:div>
<xsd:simpleType name="unitListTypeType" id="st.unitListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of unitList.</h:div><h:div class="description">Required to differentiate between the two types of
unitList (units and unitTypes)</h:div><!-- <h:div class="example" href="unit2.xml"></h:div>--></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:enumeration value="unit"><xsd:annotation><xsd:documentation><h:div class="description">child elements are unit</h:div></xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value="unitType"><xsd:annotation><xsd:documentation><h:div class="description">child elements are unitType</h:div></xsd:documentation></xsd:annotation></xsd:enumeration></xsd:restriction></xsd:simpleType>
Simple Type versionType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">Version of a document or code.</h:div><h:div class="description">Forms include 1, 0.9, 1.1.3, 1.2alpha, etc.</h:div><h:div class="example" href="version1.xml"/>
Diagram
Type
restriction of xsd:string
Facets
pattern
[0-9]+(\.[0-9]+[A-Za-z0-9\.\-_]*)*
Source
<xsd:simpleType name="versionType" id="st.versionType"><xsd:annotation><xsd:documentation><h:div class="summary">Version of a document or code.</h:div><h:div class="description">Forms include 1, 0.9, 1.1.3, 1.2alpha, etc.</h:div><h:div class="example" href="version1.xml"/></xsd:documentation></xsd:annotation><xsd:restriction base="xsd:string"><xsd:pattern value="[0-9]+(\.[0-9]+[A-Za-z0-9\.\-_]*)*"/></xsd:restriction></xsd:simpleType>
Simple Type xmlElementType
Namespace
http://www.xml-cml.org/schema
Annotations
<h:div class="summary">The name of an XMLElement.</h:div><h:div class="description"><h:p>(Distinguish from a chemical element as in elementTypeType).
Currently used for assigning XMLElement types to references (e.g. to='a1' toType='atom').
Semantics are not controlled and in principle elements outside the CML tagSet
could be used. Implementers cannot assume that namespace prefixes can be resolved
and default usage is probably the local name.</h:p></h:div>
<xsd:simpleType name="xmlElementType" id="st.xmlElementType"><xsd:annotation><xsd:documentation><h:div class="summary">The name of an XMLElement.</h:div><h:div class="description"><h:p>(Distinguish from a chemical element as in elementTypeType).
Currently used for assigning XMLElement types to references (e.g. to='a1' toType='atom').
Semantics are not controlled and in principle elements outside the CML tagSet
could be used. Implementers cannot assume that namespace prefixes can be resolved
and default usage is probably the local name.</h:p></h:div></xsd:documentation></xsd:annotation><xsd:restriction base="refType"/></xsd:simpleType>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
<xsd:attribute id="att.id" name="id" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
<xsd:attribute id="att.convention" name="convention" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
<xsd:attribute id="att.dictRef" name="dictRef" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/><!--
<h:div class="example" href="dictRefGroup2.xml"></h:div>
--></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
<xsd:attribute name="value" id="att.value" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div>
<xsd:attribute name="objectClass" type="xsd:string" id="att.objectClass"><xsd:annotation><xsd:documentation><h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.title" name="title" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A title on an element.</h:div><h:div class="description">No controlled value.</h:div><h:div class="example" href="title1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A list of three references to atoms.</h:div><h:div class="description">Typically used for defining angles,
but could also be used to define a three-centre bond.</h:div>
<xsd:attribute id="att.atomRefs3" name="atomRefs3" type="atomRefs3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A list of three references to atoms.</h:div><h:div class="description">Typically used for defining angles,
but could also be used to define a three-centre bond.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.angleUnits" name="units" type="angleUnitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Restricts units to radians or degrees.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
<xsd:attribute id="att.errorValue" name="errorValue" type="errorValueType"><xsd:annotation><xsd:documentation><h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.errorBasis" name="errorBasis" type="errorBasisType"><xsd:annotation><xsd:documentation><h:div class="summary">Basis of the error estimate.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.min" name="min" type="minType"><xsd:annotation><xsd:documentation><h:div class="summary">The minimum value allowed for an element or attribute.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.max" name="max" type="maxType"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum value allowed for an element or attribute.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
<xsd:attribute id="att.ref" name="ref" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
<xsd:attribute id="att.dataType" name="dataType" type="dataTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
<xsd:attribute id="att.units" name="units" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
<xsd:attribute id="att.constantToSI" name="constantToSI" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
<xsd:attribute id="att.multiplierToSI" name="multiplierToSI" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
<xsd:attribute id="att.unitType" name="unitType" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div>
<xsd:attribute id="att.errorValueArray" name="errorValueArray" type="errorValueArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div>
<xsd:attribute name="minValueArray" type="floatArrayType" id="att.minValueArray"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div>
<xsd:attribute name="maxValueArray" type="floatArrayType" id="att.maxValueArray"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="start" type="xsd:string" id="att.start"><xsd:annotation><xsd:documentation><h:div class="summary">The start value.</h:div><h:div class="description">The start value in any allowable
XSD representation</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="end" type="xsd:string" id="att.end"><xsd:annotation><xsd:documentation><h:div class="summary">The end value.</h:div><h:div class="description">The end value in any allowable XSD representation
of data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
<xsd:attribute id="att.delimiter" name="delimiter" type="delimiterType"><xsd:annotation><xsd:documentation><h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.size" name="size" type="sizeType"><xsd:annotation><xsd:documentation><h:div class="summary">The size of an array or matrix.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="matrixType" type="matrixType" id="att.matrixType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of matrix.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanis.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The metadata type.</h:div><h:div class="description">This is likely to be the Dublin Core
name or something similar. The use of "type" is an infelicitous
misnomer and we shall try to remove it.</h:div>
<xsd:attribute name="name" type="metadataType" id="att.metadataType"><xsd:annotation><xsd:documentation><h:div class="summary">The metadata type.</h:div><h:div class="description">This is likely to be the Dublin Core
name or something similar. The use of "type" is an infelicitous
misnomer and we shall try to remove it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
<xsd:attribute id="att.name" name="name" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
<xsd:attribute id="att.role" name="role" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="state" type="stateType" id="att.state"><xsd:annotation><xsd:documentation><h:div class="summary">The physical state of the substance.</h:div><h:div class="description">No fixed semantics or default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Constraint on a parameter.</h:div><h:div class="description">Semantics not yet finalised. We anticipate "fixed",
"none" and symbolic relationships to other parameters.</h:div>
<xsd:attribute name="constraint" id="att.constraint" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Constraint on a parameter.</h:div><h:div class="description">Semantics not yet finalised. We anticipate "fixed",
"none" and symbolic relationships to other parameters.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="type" id="att.type" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A flag on 'arg' to indicate that the value can be substituted.</h:div><h:div class="description">This is still experimental. The value may be an
XPath expression, at present
all attributes (".//@*") are processed. If an attribute contains _ijk_ where the
name of the arg is 'ijk' this string is replaced by the value of ijk,
e.g. if arg with name ijk has a value of 2 then 'm_ijk__z3' becomes
'm2_z3'. substitute="." replaces this element by its value</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<xsd:attribute name="substitute" id="att.substitute" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag on 'arg' to indicate that the value can be substituted.</h:div><h:div class="description">This is still experimental. The value may be an
XPath expression, at present
all attributes (".//@*") are processed. If an attribute contains _ijk_ where the
name of the arg is 'ijk' this string is replaced by the value of ijk,
e.g. if arg with name ijk has a value of 2 then 'm_ijk__z3' becomes
'm2_z3'. substitute="." replaces this element by its value</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">parameter name passed to an element</h:div><h:div class="description">This is still experimental.</h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
<xsd:attribute name="parameterName" id="att.parameterName" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">parameter name passed to an element</h:div><h:div class="description">This is still experimental.</h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">raplaces attribute on parent</h:div><h:div class="description">This is still experimental. Creates, overwriting
if necessary, an attribute on parent. Example:<h:pre><foo>
<arg parentAttribute="bar">zubbo</arg></h:pre>will create an attribute bar="zubbo" on <foo></h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
<xsd:attribute name="parentAttribute" id="att.parentAttribute" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">raplaces attribute on parent</h:div><h:div class="description">This is still experimental. Creates, overwriting
if necessary, an attribute on parent. Example:<h:pre><foo>
<arg parentAttribute="bar">zubbo</arg></h:pre>will create an attribute bar="zubbo" on <foo></h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A flag indicated that the element can detach/delete itself.</h:div><h:div class="description">An element containg this attribute may only have a transient existence
(e.g. a template to create other elements) and this attribute shows that
the element can be deleted at the appropriate stage. The time at which this
is called is application dependent. At present the presence of the attribute
is sufficient to trigger this; later a controlled vocabulary will be developed.</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<xsd:attribute name="delete" id="att.delete" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag indicated that the element can detach/delete itself.</h:div><h:div class="description">An element containg this attribute may only have a transient existence
(e.g. a template to create other elements) and this attribute shows that
the element can be deleted at the appropriate stage. The time at which this
is called is application dependent. At present the presence of the attribute
is sufficient to trigger this; later a controlled vocabulary will be developed.</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A flag on 'arg' to indicate that the value can be calculated.</h:div><h:div class="description">This is still experimental. if eval="_ijk_+3" and
the value of the ijk was 2, this would change the value of the arg to 5.
Only + and - are currently allowed</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
<xsd:attribute name="eval" id="att.eval" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag on 'arg' to indicate that the value can be calculated.</h:div><h:div class="description">This is still experimental. if eval="_ijk_+3" and
the value of the ijk was 2, this would change the value of the arg to 5.
Only + and - are currently allowed</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.atomRef" name="atomRef" type="atomRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an atom.</h:div><h:div class="description">Used by bond, electron, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="atomRefs" id="att.atomRefs" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a list of atoms.</h:div><h:div class="description">Used by bonds, electrons, atomSets, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="bondRef" id="att.bondRef" type="bondRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a bond.</h:div><h:div class="description">used by electron, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="bondRefs" id="att.bondRefs" type="bondRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a list of bonds.</h:div><h:div class="description">Used by electrons, bondSets, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
<xsd:attribute id="att.count" name="count" type="positiveNumberType"><xsd:annotation><xsd:documentation><h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div>
<xsd:attribute id="att.atomRefs4" name="atomRefs4" type="atomRefs4Type"><xsd:annotation><xsd:documentation><h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.atomRefArray" name="atomRefArray" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of references to atoms.</h:div><h:div class="description">Typical use would be to atoms defining a plane.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The value of an element with a _convention_.</h:div><h:div class="description">When convention is used this attribute must be present and element content must be empty.</h:div>
<xsd:attribute name="conventionValue" id="att.conventionValue" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The value of an element with a _convention_.</h:div><h:div class="description">When convention is used this attribute must be present and element content must be empty.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div>
<xsd:attribute name="atomRefs2" id="att.atomRefs2" type="atomRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
<xsd:attribute id="att.order" name="order" type="orderType"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="bondID" id="att.bondIDArray" type="bondRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The IDs for an array of bond.</h:div><h:div class="general">Required in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="atomRef1" id="att.atomRef1Array" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The first atoms in each bond.</h:div><h:div class="description">Currently only used in bondArray in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="atomRef2" id="att.atomRef2Array" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The second atoms in each bond.</h:div><h:div class="general">Only used in bondArray in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
<xsd:attribute name="order" id="att.orderArray" type="orderArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.cellParameterType" name="type" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The type of a cellParameter.</h:div><h:div class="description">length or angle</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A point group.</h:div><h:div class="description">No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future.</h:div>
<xsd:attribute id="att.pointGroup" name="pointGroup" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A point group.</h:div><h:div class="description">No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A space group.</h:div><h:div class="description">No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future.</h:div>
<xsd:attribute id="att.spaceGroup" name="spaceGroup" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A space group.</h:div><h:div class="description">No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A symmetry species.</h:div><h:div class="description">No fixed semantics, though we may provide a controlled-extensible list in the future.</h:div>
<xsd:attribute name="irreducibleRepresentation" id="att.irreducibleRepresentation" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A symmetry species.</h:div><h:div class="description">No fixed semantics, though we may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div>
<xsd:attribute id="att.number" name="number" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The number of molecules per cell.</h:div><h:div class="description">Molecules are defined as the _molecule_ which directly contains the _crystal_ element.</h:div>
<xsd:attribute id="att.z" name="z" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">The number of molecules per cell.</h:div><h:div class="description">Molecules are defined as the _molecule_ which directly contains the _crystal_ element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<xsd:attribute id="att.formalCharge" name="formalCharge" type="formalChargeType"><xsd:annotation><xsd:documentation><h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A concise formula.</h:div><h:div class="general">The string represents an (unstructured) formula i.e. no submolecules.
Recommended to use the format "H 2 O 1", etc.</h:div>
<xsd:attribute name="concise" id="att.concise" type="formulaType"><xsd:annotation><xsd:documentation><h:div class="summary">A concise formula.</h:div><h:div class="general">The string represents an (unstructured) formula i.e. no submolecules.
Recommended to use the format "H 2 O 1", etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An inline representation of the object.</h:div><h:div class="general">This can represent a wide range of information from formal serialization
as ASCII through to domain-specific textual representations. It will often be used in conjunction
with the "convention" attribute. For example it could be used to represent IUPAC formula,
SMILES strings, TeX equations, etc. Characters should conforma to the XML character set,
and XML markup (lt and amp) should be escaped.<h:b>IT SHOULD NEVER BE USED FOR INLINE XML</h:b></h:div><h:div class="example" href="attributeGroups/inline.xml"/>
<xsd:attribute name="inline" id="att.inline" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">An inline representation of the object.</h:div><h:div class="general">This can represent a wide range of information from formal serialization
as ASCII through to domain-specific textual representations. It will often be used in conjunction
with the "convention" attribute. For example it could be used to represent IUPAC formula,
SMILES strings, TeX equations, etc. Characters should conforma to the XML character set,
and XML markup (lt and amp) should be escaped.<h:b>IT SHOULD NEVER BE USED FOR INLINE XML</h:b></h:div><h:div class="example" href="attributeGroups/inline.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div>
<xsd:attribute id="att.version" name="version" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Indicates whether the structure is a tautomer.</h:div><h:div class="general">Currently used with IChI _identifier_ element. Semantics, vocabulary and usage are application-dependent.</h:div>
<xsd:attribute id="att.tautomeric" name="tautomeric" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Indicates whether the structure is a tautomer.</h:div><h:div class="general">Currently used with IChI _identifier_ element. Semantics, vocabulary and usage are application-dependent.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">References to two different molecules.</h:div><h:div class="description">Available for any reference to molecules but
normally will be the normal reference attribute on the join element.
The order of molecules is preserved and may matter.</h:div><h:div class="curation">2006-11-24: PMR created</h:div>
<xsd:attribute name="moleculeRefs2" id="att.moleculeRefs2" type="moleculeRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">References to two different molecules.</h:div><h:div class="description">Available for any reference to molecules but
normally will be the normal reference attribute on the join element.
The order of molecules is preserved and may matter.</h:div><h:div class="curation">2006-11-24: PMR created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Allows a referring element to generate a unique id.</h:div><h:div class="description">idgen can hold a unique identifier which is copied into the id
attribute of the referenced element. This avoids multiple copies of the referenced
object with duplicate ids. EXPERIMENTAL</h:div><h:div class="curation">2006-05-22: PMR added.</h:div>
<xsd:attribute id="att.idgen" name="idgen" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Allows a referring element to generate a unique id.</h:div><h:div class="description">idgen can hold a unique identifier which is copied into the id
attribute of the referenced element. This avoids multiple copies of the referenced
object with duplicate ids. EXPERIMENTAL</h:div><h:div class="curation">2006-05-22: PMR added.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Keyword signifying how object is to be processed.</h:div><h:div class="description">Semantics depend on the parent element</h:div><h:div class="curation">2006-05-20: PMR added</h:div>
<xsd:attribute id="att.process" name="process" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Keyword signifying how object is to be processed.</h:div><h:div class="description">Semantics depend on the parent element</h:div><h:div class="curation">2006-05-20: PMR added</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Simple chemical formula.</h:div><h:div class="general">This attribute should only be used for simple formulae (i.e. without brackets or other nesting for which a _formula_ child element should be used. The attribute might be used as a check on the child elements or for ease of representation. Essentially the same as _concise_ attribute on _formula.</h:div>
<xsd:attribute id="att.formula" name="formula" type="formulaType"><xsd:annotation><xsd:documentation><h:div class="summary">Simple chemical formula.</h:div><h:div class="general">This attribute should only be used for simple formulae (i.e. without brackets or other nesting for which a _formula_ child element should be used. The attribute might be used as a check on the child elements or for ease of representation. Essentially the same as _concise_ attribute on _formula.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div>
<xsd:attribute name="chirality" id="att.chirality" type="chiralityType"><xsd:annotation><xsd:documentation><h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div>
<xsd:attribute id="att.spinMultiplicity" name="spinMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Is the molecule oriented to the symmetry</h:div><h:div class="description">No formal default, but a molecule is assumed to be oriented according to any _symmetry_ children. This is required for crystallographic data, but some systems for isolated molecules allow specification of arbitrary Cartesian or internal coordinates, which must be fitted or refined to a prescribed symmetry. In this case the attribute value is false.</h:div>
<xsd:attribute id="att.symmetryOriented" name="symmetryOriented" type="xsd:boolean"><xsd:annotation><xsd:documentation><h:div class="summary">Is the molecule oriented to the symmetry</h:div><h:div class="description">No formal default, but a molecule is assumed to be oriented according to any _symmetry_ children. This is required for crystallographic data, but some systems for isolated molecules allow specification of arbitrary Cartesian or internal coordinates, which must be fitted or refined to a prescribed symmetry. In this case the attribute value is false.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div>
<xsd:attribute id="att.x3" name="x3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
<xsd:attribute id="att.y3" name="y3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
<xsd:attribute id="att.z3" name="z3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.elementType" name="elementType" type="elementTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Number of hydrogens.</h:div><h:div class="description">The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
<xsd:attribute id="att.hydrogenCount" name="hydrogenCount" type="hydrogenCountType"><xsd:annotation><xsd:documentation><h:div class="summary">Number of hydrogens.</h:div><h:div class="description">The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.isotope" name="isotope" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The isotope for an element.</h:div><h:div class="description">A real number describing the isotope. Probably obsolet.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The integer number for an isotope.</h:div><h:div class="description">The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef).</h:div>
<xsd:attribute id="att.isotopeNumber" name="isotopeNumber" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">The integer number for an isotope.</h:div><h:div class="description">The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef).</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Reference to a fuller description of the isotope.</h:div><h:div class="general">The description may be found in an external collection (e.g. IUPAC) or within the current document.</h:div><h:div class="example" href="isotope2.xml"/>
<xsd:attribute id="att.isotopeRef" name="isotopeRef" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">Reference to a fuller description of the isotope.</h:div><h:div class="general">The description may be found in an external collection (e.g. IUPAC) or within the current document.</h:div><h:div class="example" href="isotope2.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Reference to a description of the isotopic composition of an atom.</h:div><h:div class="description">Used when more than one atom shares the same isotopic composition (e.g. when H/D have been scrambled over some or all of the atoms in a molecule..</h:div><h:div class="example" href="isotope1.xml"/>
<xsd:attribute id="att.isotopeListRef" name="isotopeListRef" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">Reference to a description of the isotopic composition of an atom.</h:div><h:div class="description">Used when more than one atom shares the same isotopic composition (e.g. when H/D have been scrambled over some or all of the atoms in a molecule..</h:div><h:div class="example" href="isotope1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Occupancy for an atom.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms.</h:div>
<xsd:attribute id="att.occupancy" name="occupancy" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">Occupancy for an atom.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">x2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<xsd:attribute name="x2" id="att.x2" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">x2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">y2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2
dimensions. Unrelated to the 3-D coordinates for the object. The
orientation of the axes matters as it can affect the chirality of
object.</h:div>
<xsd:attribute id="att.y2" name="y2" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">y2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2
dimensions. Unrelated to the 3-D coordinates for the object. The
orientation of the axes matters as it can affect the chirality of
object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<xsd:attribute id="att.xFract" name="xFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
<xsd:attribute id="att.yFract" name="yFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
<xsd:attribute id="att.zFract" name="zFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the spaceGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 192. It represents the number of symmetry operations
(without cell translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a spaceGroupMultiplicity of 2.
The spaceGroupMultiplicity can be deduced from a knowledge of the
coordinates and the spaceGroup operators and so is formally redundant but this is a
useful convenience operator. Some crystallographic experiments report this attribute
as, for example, the IUCr CIF item 'atom_site_symmetry_multiplicity'.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
<xsd:attribute id="att.spaceGroupMultiplicity" name="spaceGroupMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the spaceGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 192. It represents the number of symmetry operations
(without cell translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a spaceGroupMultiplicity of 2.
The spaceGroupMultiplicity can be deduced from a knowledge of the
coordinates and the spaceGroup operators and so is formally redundant but this is a
useful convenience operator. Some crystallographic experiments report this attribute
as, for example, the IUCr CIF item 'atom_site_symmetry_multiplicity'.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the pointGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 60 (for icosahedral). It represents the number of symmetry operations
(without any translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a pointGroupMultiplicity of 2.
The pointGroupMultiplicity can be deduced from a knowledge of the
coordinates and the pointGroup operators and so is formally redundant but this is a
useful convenience operator.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
<xsd:attribute id="att.pointGroupMultiplicity" name="pointGroupMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the pointGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 60 (for icosahedral). It represents the number of symmetry operations
(without any translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a pointGroupMultiplicity of 2.
The pointGroupMultiplicity can be deduced from a knowledge of the
coordinates and the pointGroup operators and so is formally redundant but this is a
useful convenience operator.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.elementTypeArray" name="elementType" type="elementTypeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of object counts.</h:div><h:div class="description">No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value.</h:div>
<xsd:attribute id="att.countArray" name="count" type="countArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of object counts.</h:div><h:div class="description">No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An array of formalCharges.</h:div><h:div class="description">Used in CML2 Array mode. NOT the calculated charge or oxidation state. No formal defaults, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
<xsd:attribute id="att.formalChargeArray" name="formalCharge" type="formalChargeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of formalCharges.</h:div><h:div class="description">Used in CML2 Array mode. NOT the calculated charge or oxidation state. No formal defaults, but assumed to be zero if omitted. It may become good practice to include it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">Normally used in CML2 array mode. The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
<xsd:attribute id="att.hydrogenCountArray" name="hydrogenCount" type="hydrogenCountArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">Normally used in CML2 array mode. The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of occupancies.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms.</h:div>
<xsd:attribute id="att.occupancyArray" name="occupancy" type="occupancyArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of occupancies.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">array of x2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<xsd:attribute name="x2" id="att.x2Array" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">array of x2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">array of y2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
<xsd:attribute id="att.y2Array" name="y2" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">array of y2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.x3Array" name="x3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of x3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.y3Array" name="y3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of y3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.z3Array" name="z3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of z3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<xsd:attribute id="att.xFractArray" name="xFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<xsd:attribute id="att.yFractArray" name="yFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of fractional z coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
<xsd:attribute id="att.zFractArray" name="zFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional z coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="atomID" id="att.atomIDArray" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of atom IDs.</h:div><h:div class="description">Normally an attribute of an array-based element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="order" id="att.actionOrder" type="actionOrderType"><xsd:annotation><xsd:documentation><h:div class="summary">Describes whether child elements are sequential or parallel.</h:div><h:div class="description">There is no default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div>
<xsd:attribute name="type" id="att.alternativeType" type="alternativeTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a map providing mappings between atoms</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking atoms. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of atoms are of equal size and have 1:1 mapping between each id. This is another way of saying that the atoms mapped by a given ID are "the same atom".</h:div>
<xsd:attribute id="att.atomMap" name="atomMap" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between atoms</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking atoms. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of atoms are of equal size and have 1:1 mapping between each id. This is another way of saying that the atoms mapped by a given ID are "the same atom".</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An atomSet describing the region.</h:div><h:div class="description">Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments.</h:div>
<xsd:attribute name="atomSetRef" type="refType" id="att.atomSetRef"><xsd:annotation><xsd:documentation><h:div class="summary">An atomSet describing the region.</h:div><h:div class="description">Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a map providing mappings between bonds</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking bonds. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of bonds are of equal size and have 1:1 mapping between each id. This is another way of saying that the bonds mapped by a given ID are "the same bond".</h:div>
<xsd:attribute id="att.bondMap" name="bondMap" type="xsd:QName"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between bonds</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking bonds. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of bonds are of equal size and have 1:1 mapping between each id. This is another way of saying that the bonds mapped by a given ID are "the same bond".</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A parallelipiped box.</h:div><h:div class="description">By default the box uses isometric Cartesians axes but can also be linked to lattice Vector. Any point falling within the box or on a boundary is within the regio.</h:div>
<xsd:attribute name="box3" type="box3Type" id="att.box3"><xsd:annotation><xsd:documentation><h:div class="summary">A parallelipiped box.</h:div><h:div class="description">By default the box uses isometric Cartesians axes but can also be linked to lattice Vector. Any point falling within the box or on a boundary is within the regio.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.constantToData" name="constantToData" type="xsd:double" default="0.0"><xsd:annotation><xsd:documentation><h:div class="summary">The constant to add to the raw data.</h:div><h:div class="description">add *after* applying any multiplier.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">General formula for the repeat count of the element.</h:div><h:div class="description">Experimental.
No fixed semantics or default.</h:div>
<xsd:attribute id="att.countExpression" name="countExpression" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">General formula for the repeat count of the element.</h:div><h:div class="description">Experimental.
No fixed semantics or default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">default value in an enumeration.</h:div><h:div class="description">A non-whitespace string (value is irrelevant) indicates that the content of this enumeration is the default value (usually of a scalar). It is an error to have more than one default. If the scalar in an instance document has no value (i.e. is empty or contains only whitespace) its value is given by the default. If the scalar in the instance is empty and no enumerations have a default attribute, an application may throw an error.</h:div>
<xsd:attribute name="default" type="xsd:string" id="att.default"><xsd:annotation><xsd:documentation><h:div class="summary">default value in an enumeration.</h:div><h:div class="description">A non-whitespace string (value is irrelevant) indicates that the content of this enumeration is the default value (usually of a scalar). It is an error to have more than one default. If the scalar in an instance document has no value (i.e. is empty or contains only whitespace) its value is given by the default. If the scalar in the instance is empty and no enumerations have a default attribute, an application may throw an error.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div>
<xsd:attribute id="att.dictionaryPrefix" name="dictionaryPrefix" type="dictionaryPrefixType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Dimensionality of a coordinate system.</h:div><h:div class="description">Note that this means that coordinates of higher dimensionality
are ignored or an error is flagged. Thus z3 and dimensionality='2' are incompatible.
At present higher dimensionalities than 3 (cf. Wondratschek) are not supported.
The labelling of the axes id not controlled. ?? should we have an explicit
attribute for labelling convention?.</h:div>
<xsd:attribute name="dimensionality" id="att.dimensionality" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Dimensionality of a coordinate system.</h:div><h:div class="description">Note that this means that coordinates of higher dimensionality
are ignored or an error is flagged. Thus z3 and dimensionality='2' are incompatible.
At present higher dimensionalities than 3 (cf. Wondratschek) are not supported.
The labelling of the axes id not controlled. ?? should we have an explicit
attribute for labelling convention?.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The basis of the dimension.</h:div><h:div class="description">Normally taken from the seven SI types but possibly expandable.</h:div>
<xsd:attribute name="dimensionBasis" type="dimensionType" id="att.dimensionBasis"><xsd:annotation><xsd:documentation><h:div class="summary">The basis of the dimension.</h:div><h:div class="description">Normally taken from the seven SI types but possibly expandable.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The orientation of the eigenvector matrix.</h:div><h:div class="description">Describes whether the vectors are columns or
rows. No default, so effectively mandatory unless you want to make implementers
guess and break applications.</h:div>
<xsd:attribute name="orientation" type="eigenOrientationType" id="att.eigenOrientation"><xsd:annotation><xsd:documentation><h:div class="summary">The orientation of the eigenvector matrix.</h:div><h:div class="description">Describes whether the vectors are columns or
rows. No default, so effectively mandatory unless you want to make implementers
guess and break applications.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a map providing mappings between electrons</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking electrons. The topology of the linking is defined by the application - it could be reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of electrons are of equal size and have 1:1 mapping between each id. This is another way of saying that the electrons mapped by a given ID are "the same electron".</h:div>
<xsd:attribute id="att.electronMap" name="electronMap" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between electrons</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking electrons. The topology of the linking is defined by the application - it could be reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of electrons are of equal size and have 1:1 mapping between each id. This is another way of saying that the electrons mapped by a given ID are "the same electron".</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div>
<xsd:attribute name="endCondition" type="xsd:string" id="att.endCondition"><xsd:annotation><xsd:documentation><h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Information identifying the name of a file or other resource.</h:div><h:div class="description">This allows an element (such as cml) to carry limited
information about provenance such as the name of the document used to provide the
content. It is not a complete solution but can help to protect a document becoming
separated from its external metadata. It is restricted to the basic XML character set
(printable ANSI) and whitespace (which should anyway be discouraged) is normalized to
single space (attribute values cannot carry newlines).
Quotation marks and other horrors (as used in some OS)
should be avoided.</h:div>
<xsd:attribute id="att.fileId" name="fileId" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Information identifying the name of a file or other resource.</h:div><h:div class="description">This allows an element (such as cml) to carry limited
information about provenance such as the name of the document used to provide the
content. It is not a complete solution but can help to protect a document becoming
separated from its external metadata. It is restricted to the basic XML character set
(printable ANSI) and whitespace (which should anyway be discouraged) is normalized to
single space (attribute values cannot carry newlines).
Quotation marks and other horrors (as used in some OS)
should be avoided.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="form" id="att.form" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a functional form.</h:div><h:div class="description">Currently used for potential.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div>
<xsd:attribute id="att.format" name="format" type="formatType"><xsd:annotation><xsd:documentation><h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Number of digits after the point.</h:div><h:div class="description">This is used in dictionaries to define precision. However it might be replaced by xsd:facet.</h:div>
<xsd:attribute id="att.fractionDigits" name="fractionDigits" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Number of digits after the point.</h:div><h:div class="description">This is used in dictionaries to define precision. However it might be replaced by xsd:facet.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The base of one or more links.</h:div><h:div class="description">On link elements the value is the single id of an element within the document or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
<xsd:attribute id="att.from" name="from" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">The base of one or more links.</h:div><h:div class="description">On link elements the value is the single id of an element within the document or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.fromContext" name="fromContext" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.fromSet" name="fromSet" type="idArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.fromType" name="fromType" type="xmlElementType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div>
<xsd:attribute id="att.ft" name="ft" default="none" type="ftType"><xsd:annotation><xsd:documentation><h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
<xsd:attribute id="att.href" name="href" type="xsd:anyURI"><xsd:annotation><xsd:documentation><h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div>
<h:div class="summary">Values from this element will be merged.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will not conflict with the existing information. It is an error if there is a conflict.</h:div>
enumeration
replace
<h:div class="summary">Values from this element will replace existing information.</h:div><h:div class="description">The merging is element-specific with the intention that information from the current element will replace the existing information.</h:div>
enumeration
delete
<h:div class="summary">Components of this element will de deleted if they exist.</h:div>
<xsd:attribute id="att.inherit" name="inherit" type="inheritType"><xsd:annotation><xsd:documentation><h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div>
<xsd:attribute id="att.integral" name="integral" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">indicates whether a unit is an SI or derived SI unit.</h:div><h:div class="description">required on SI unit elements with value 'true'.
Optional on other units with attribute 'false'. A unitList should contain either
SI units or non-SI units but not both.</h:div>
<xsd:attribute name="isSI" id="att.isSI" type="xsd:boolean"><xsd:annotation><xsd:documentation><h:div class="summary">indicates whether a unit is an SI or derived SI unit.</h:div><h:div class="description">required on SI unit elements with value 'true'.
Optional on other units with attribute 'false'. A unitList should contain either
SI units or non-SI units but not both.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to a kpoint.</h:div><h:div class="description">Used by band, etc.</h:div><h:div class="curation">2006-01-21: PMR. Created</h:div>
<h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div>
<xsd:attribute name="label" type="xsd:string" id="att.label"><xsd:annotation><xsd:documentation><h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The primitivity of a lattice.</h:div><h:div class="description">No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency between spacegroups, symmetry operators, etc.</h:div>
<xsd:attribute id="att.latticeType" name="latticeType" type="latticeType"><xsd:annotation><xsd:documentation><h:div class="summary">The primitivity of a lattice.</h:div><h:div class="description">No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency between spacegroups, symmetry operators, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.length" name="length" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Length of a scalar.</h:div><h:div class="description">Probably will be replaced with xsd:schema tool.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="linkType" id="att.linkType" type="linkTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the link.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A list of values.</h:div><h:div class="description">Normally for iterations.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div>
<xsd:attribute name="list" type="xsd:string" id="att.list"><xsd:annotation><xsd:documentation><h:div class="summary">A list of values.</h:div><h:div class="description">Normally for iterations.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An attribute providing a mandatory unique ID for an element.</h:div><h:div class="description">This is a horrible hack. It should be possible to add 'required' to
the attributeGroup where used... (Maybe it is and I am still fighting Schema Wars.</h:div>
<xsd:attribute id="att.mandatoryId" name="id" type="idType" use="required"><xsd:annotation><xsd:documentation><h:div class="summary">An attribute providing a mandatory unique ID for an element.</h:div><h:div class="description">This is a horrible hack. It should be possible to add 'required' to
the attributeGroup where used... (Maybe it is and I am still fighting Schema Wars.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.maxLength" name="maxLength" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">maximum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schem.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div>
<xsd:attribute id="att.measurement" name="measurement" type="measurementType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.minLength" name="minLength" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">minimum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schema.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.moleculeRef" name="moleculeRef" type="moleculeRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a molecule.</h:div><h:div class="description">Used by spectrum, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div>
<xsd:attribute name="moleculeRefs" id="att.moleculeRefs" type="moleculeRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div>
<xsd:attribute id="att.multiplierToData" name="multiplierToData" type="xsd:double" default="1.0"><xsd:annotation><xsd:documentation><h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div>
<xsd:attribute id="att.namespace" name="namespace" type="namespaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/>
<xsd:attribute id="att.parentSI" name="parentSI" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div>
<xsd:attribute id="att.peakHeight" name="peakHeight" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.peakMultiplicity" name="peakMultiplicity" type="peakMultiplicityType"><xsd:annotation><xsd:documentation><h:div class="summary">Multiplicity of a peak.</h:div><h:div class="description">Uses a semi-controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.peakShape" name="peakShape" type="peakShapeType"><xsd:annotation><xsd:documentation><h:div class="summary">Shape of a peak.</h:div><h:div class="description">Semi-controlled vocabulary such as broad or sharp.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.peakStructureType" name="type" type="peakStructureTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of this structure.</h:div><h:div class="description">Semi-controlled vocabulary such as coupling
or splitting.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div>
<xsd:attribute id="att.peakUnits" name="peakUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Is the axis periodic.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or 2D layer. The third vector is orthogonal and represents coordinates normal to the surface. In this case only the direction, not the magnitude of the vector is important.</h:div>
<xsd:attribute name="periodic" type="xsd:boolean" id="att.periodic" default="true"><xsd:annotation><xsd:documentation><h:div class="summary">Is the axis periodic.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or 2D layer. The third vector is orthogonal and represents coordinates normal to the surface. In this case only the direction, not the magnitude of the vector is important.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Periodicity of the system.</h:div><h:div class="summary">This represents the number of dimensions (or coordinate axes) along periodic behaviour occurs and can be supported by symmetry operators or other transformations. Periodicity must never exceed dimensionality.</h:div>
<xsd:attribute name="periodicity" id="att.periodicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Periodicity of the system.</h:div><h:div class="summary">This represents the number of dimensions (or coordinate axes) along periodic behaviour occurs and can be supported by symmetry operators or other transformations. Periodicity must never exceed dimensionality.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A point in 3 dimensions.</h:div><h:div class="description">can be used for any complex
geometrical object, such as line.</h:div>
<xsd:attribute name="point3" type="point3Type" id="att.point3"><xsd:annotation><xsd:documentation><h:div class="summary">A point in 3 dimensions.</h:div><h:div class="description">can be used for any complex
geometrical object, such as line.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
<xsd:attribute name="power" type="xsd:double" id="att.power"><xsd:annotation><xsd:documentation><h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
<xsd:attribute name="power" type="xsd:double" use="required" id="att.powerRequired"><xsd:annotation><xsd:documentation><h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div>
<xsd:attribute name="preserve" type="xsd:boolean" id="att.preserve"><xsd:annotation><xsd:documentation><h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A ratio in the range 0 to 1.</h:div><h:div class="description">Currently used for ratios between brached reactions but re-usable for other concepts.</h:div>
<xsd:attribute name="ratio" id="att.ratio" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">A ratio in the range 0 to 1.</h:div><h:div class="description">Currently used for ratios between brached reactions but re-usable for other concepts.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div>
<xsd:attribute id="att.reactionFormat" name="format" type="reactionFormatType"><xsd:annotation><xsd:documentation><h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="role" id="att.reactionRole" type="reactionRoleType"><xsd:annotation><xsd:documentation><h:div class="summary">Role of the reaction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div>
<xsd:attribute name="type" id="att.reactionStepListType" default="consecutive" type="reactionStepListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.reactionType" name="type" type="reactionTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the reaction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A list of regions creating a union.</h:div><h:div class="description">The union of a series of regions produces a larger region (possibly disjoint). Any point belonging to any of the referenced regions is a member of this region.</h:div>
<xsd:attribute name="regionRefs" type="refType" id="att.regionRefs"><xsd:annotation><xsd:documentation><h:div class="summary">A list of regions creating a union.</h:div><h:div class="description">The union of a series of regions produces a larger region (possibly disjoint). Any point belonging to any of the referenced regions is a member of this region.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div>
<xsd:attribute id="att.relatedEntryType" name="type" type="relatedEntryTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div>
<xsd:attribute name="scheme" id="att.reactionStepList.scheme" default="sequence" type="schemeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Serial number or other id.</h:div><h:div class="summary">Currently only on module. Modules with the same _role_ attribute can be distinguished by _serial_. This is often an integer but other schemes may be used.</h:div>
<xsd:attribute name="serial" id="att.serial" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Serial number or other id.</h:div><h:div class="summary">Currently only on module. Modules with the same _role_ attribute can be distinguished by _serial_. This is often an integer but other schemes may be used.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="shape" type="shapeType" id="att.shape"><xsd:annotation><xsd:documentation><h:div class="summary">shape of object.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanism.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div>
<xsd:attribute id="att.siNamespace" name="siNamespace" type="namespaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Array of namespaces locating SI Units dictionaries.</h:div><h:div class="description">Main use is on unitList to identify the
dictionaries holding the SI Units.</h:div>
<xsd:attribute id="att.siNamespaceArray" name="siNamespaceArray" type="namespaceArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of namespaces locating SI Units dictionaries.</h:div><h:div class="description">Main use is on unitList to identify the
dictionaries holding the SI Units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The spaceType of the lattice.</h:div><h:div class="description">Usually real or reciprocal. No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency for unitTypes, etc.</h:div>
<xsd:attribute id="att.spaceType" name="spaceType" type="spaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The spaceType of the lattice.</h:div><h:div class="description">Usually real or reciprocal. No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency for unitTypes, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="type" id="att.spectrumType" type="spectrumTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the spectrum.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A sphere.</h:div><h:div class="description">Currently describes a region. Any point falling within the sphere or on its surface is within the region.</h:div>
<xsd:attribute name="sphere3" type="sphere3Type" id="att.sphere3"><xsd:annotation><xsd:documentation><h:div class="summary">A sphere.</h:div><h:div class="description">Currently describes a region. Any point falling within the sphere or on its surface is within the region.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The spin of a system.</h:div><h:div class="description">Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope.</h:div><h:div class="example" href="spin1.xml"/>
<xsd:attribute id="att.spin" name="spin" type="isotopicSpinType"><xsd:annotation><xsd:documentation><h:div class="summary">The spin of a system.</h:div><h:div class="description">Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope.</h:div><h:div class="example" href="spin1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div>
<xsd:attribute name="startCondition" type="xsd:string" id="att.startCondition"><xsd:annotation><xsd:documentation><h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute name="step" type="xsd:string" id="att.step"><xsd:annotation><xsd:documentation><h:div class="summary">The step value.</h:div><h:div class="description">The step value in any allowable
XSD representation</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.substanceListType" name="type" type="substanceListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div>
<xsd:attribute name="symbol" id="att.symbol" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A term in a dictionary.</h:div><h:div class="description">The term should be a noun or nounal phrase, with a separate definition and further description.</h:div>
<xsd:attribute id="att.term" name="term" type="xsd:string" use="required"><xsd:annotation><xsd:documentation><h:div class="summary">A term in a dictionary.</h:div><h:div class="description">The term should be a noun or nounal phrase, with a separate definition and further description.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The test condition on an if element.</h:div><h:div class="description">No controlled format yet.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div>
<xsd:attribute name="test" type="xsd:string" id="att.test"><xsd:annotation><xsd:documentation><h:div class="summary">The test condition on an if element.</h:div><h:div class="description">No controlled format yet.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The target of one or more links.</h:div><h:div class="summary">On link elements the value is the single id of an element within the document or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
<xsd:attribute id="att.to" name="to" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">The target of one or more links.</h:div><h:div class="summary">On link elements the value is the single id of an element within the document or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.toContext" name="toContext" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.toSet" name="toSet" type="idArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.totalDigits" name="totalDigits" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">total digits in a scalar.</h:div><h:div class="description">based on xsd:schema.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
<xsd:attribute id="att.toType" name="toType" type="xmlElementType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Needed to differentiate the rather unhappy
polymorphism of unitList/unit and unitList/unitType.</h:div><h:div class="curation">2005-12-17 PMR: Added</h:div>
<xsd:attribute id="att.unitListType" name="type" type="unitListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Needed to differentiate the rather unhappy
polymorphism of unitList/unit and unitList/unitType.</h:div><h:div class="curation">2005-12-17 PMR: Added</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A vector in 3 dimensions.</h:div><h:div class="description">can be used for any complex geometrical object,
such as line.</h:div>
<xsd:attribute name="vector3" type="vector3Type" id="att.vector3"><xsd:annotation><xsd:documentation><h:div class="summary">A vector in 3 dimensions.</h:div><h:div class="description">can be used for any complex geometrical object,
such as line.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div>
<xsd:attribute name="weight" type="xsd:double" id="att.weight"><xsd:annotation><xsd:documentation><h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<xsd:attribute id="att.whiteSpace" name="whiteSpace" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Whitespace.</h:div><h:div class="description">Attached to entry. This may be obsolete.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div>
<xsd:attribute id="att.xMax" name="xMax" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div>
<xsd:attribute id="att.xMin" name="xMin" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div>
<xsd:attribute id="att.xUnits" name="xUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div>
<xsd:attribute id="att.xValue" name="xValue" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div>
<xsd:attribute id="att.xWidth" name="xWidth" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div>
<xsd:attribute name="yield" id="att.yield" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div>
<xsd:attribute id="att.yMax" name="yMax" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div>
<xsd:attribute id="att.yMin" name="yMin" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div>
<xsd:attribute id="att.yUnits" name="yUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div>
<xsd:attribute id="att.yValue" name="yValue" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div>
<xsd:attribute id="att.yWidth" name="yWidth" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute>
<h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div>
Source
<xsd:attributeGroup id="attGp.id" name="id"><xsd:attribute id="att.id" name="id" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A unique ID for an element.</h:div><h:div class="description">Id is used for machine identification of elements and
in general should not have application semantics. It is similar to the XML ID type
as containing only alphanumerics, '_', ',' and '-' and and must start with an
alphabetic character. Ids are case sensitive. Ids should be unique within local scope,
thus all atoms within a molecule should have unique ids, but separated molecules within a
document (such as a published article) might have identical ids. Software
should be able to search local scope (e.g. all atoms within a molecule).
However this is under constant review.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/>
Source
<xsd:attributeGroup name="convention" id="attGp.convention"><xsd:attribute id="att.convention" name="convention" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a convention.</h:div><h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements,
so that a convention for<h:tt>molecule</h:tt>would by default extend to its<h:tt>bond</h:tt>and<h:tt>atom</h:tt>children. This can be overwritten
if necessary by an explicit<h:tt>convention</h:tt>.<h:p>It may be useful to create conventions with namespaces (e.g.<h:tt>iupac:name</h:tt>).
Use of<h:tt>convention</h:tt>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.</h:p><h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p></h:div><h:div class="example" id="ex" href="convGroup1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/>
Source
<xsd:attributeGroup name="dictRef" id="attGp.dictRef"><xsd:attribute id="att.dictRef" name="dictRef" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a dictionary entry.</h:div><h:div class="description">Elements in data instances such as _scalar_ may have a<h:tt>dictRef</h: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 _entry_ elements and validated against STMML Schema.<h: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.</h:p><h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p></h:div><h:div class="example" href="dictRefGroup1.xml"/><!--
<h:div class="example" href="dictRefGroup2.xml"></h:div>
--></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div>
Source
<xsd:attributeGroup id="attGp.value" name="value"><xsd:attribute name="value" id="att.value" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Value of a scalar object.</h:div><h:div class="description">The value must be consistent with the dataType of the object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div>
Source
<xsd:attributeGroup id="attGp.objectClass" name="objectClass"><xsd:attribute name="objectClass" type="xsd:string" id="att.objectClass"><xsd:annotation><xsd:documentation><h:div class="summary">The class of an object.</h:div><h:div class="description">The type of this information. This is not controlled, but examples might include:<h:ul><h:li>label</h:li><h:li>summary</h:li><h:li>note</h:li><h:li>usage</h:li><h:li>qualifier</h:li></h:ul>It might be used to control display or XSL filtering.</h:div><h:div class="note">The attribute is named 'objectClass' to avoid clashes with other class attributes and inappropriate conversion to foo.getClass().</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A list of three references to atoms.</h:div><h:div class="description">Typically used for defining angles,
but could also be used to define a three-centre bond.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRefs3" name="atomRefs3"><xsd:attribute id="att.atomRefs3" name="atomRefs3" type="atomRefs3Type"><xsd:annotation><xsd:documentation><h:div class="summary">A list of three references to atoms.</h:div><h:div class="description">Typically used for defining angles,
but could also be used to define a three-centre bond.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Restricts units to radians or degrees.</h:div><h:div class="description"/>
Source
<xsd:attributeGroup id="attGp.angleUnits" name="angleUnits"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.angleUnits" name="units" type="angleUnitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Restricts units to radians or degrees.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div>
Source
<xsd:attributeGroup id="attGp.errorValue" name="errorValue"><xsd:attribute id="att.errorValue" name="errorValue" type="errorValueType"><xsd:annotation><xsd:documentation><h:div class="summary">Value of the error.</h:div><h:div class="description">Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real number.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The minimum value allowed for an element or attribute.</h:div><h:div class="description"/>
Source
<xsd:attributeGroup id="attGp.min" name="min"><xsd:attribute id="att.min" name="min" type="minType"><xsd:annotation><xsd:documentation><h:div class="summary">The minimum value allowed for an element or attribute.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Maximum value allowed for an element or attribute.</h:div><h:div class="description"/>
Source
<xsd:attributeGroup id="attGp.max" name="max"><xsd:attribute id="att.max" name="max" type="maxType"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum value allowed for an element or attribute.</h:div><h:div class="description"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/>
Source
<xsd:attributeGroup id="attGp.ref" name="ref"><xsd:attribute id="att.ref" name="ref" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to an element of given type.</h:div><h:div class="description"><h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the document. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.<br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div><h:div class="example" href="refGroup1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div>
Source
<xsd:attributeGroup id="attGp.dataType" name="dataType"><xsd:attribute id="att.dataType" name="dataType" type="dataTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The data type of the object.</h:div><h:div class="description">Normally applied to scalar/array
objects but may extend to more complex one.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div>
Source
<xsd:attributeGroup id="attGp.units" name="units"><xsd:attribute id="att.units" name="units" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Scientific units on an element.</h:div><h:div class="description">These must be taken from a dictionary
of units. There should be some mechanism for validating the type
of the units against the possible values of the element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div>
Source
<xsd:attributeGroup id="attGp.constantToSI" name="constantToSI"><xsd:attribute id="att.constantToSI" name="constantToSI" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Additive constant to generate SI equivalent.</h:div><h:div class="description">The amount to add to a quantity in non-SI units to convert its representation to SI Units. This is applied *after* multiplierToSI. It is necessarily zero for SI units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div>
Source
<xsd:attributeGroup id="attGp.multiplierToSI" name="multiplierToSI"><xsd:attribute id="att.multiplierToSI" name="multiplierToSI" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Multiplier to generate SI equivalent.</h:div><h:div class="description">The factor by which the non-SI unit should be multiplied to convert a quantity to its representation in SI Units. This is applied *before* _constantToSI_. Necessarily unity for SI unit.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div>
Source
<xsd:attributeGroup id="attGp.unitType" name="unitType"><xsd:attribute id="att.unitType" name="unitType" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Used in defining the unit and doing
symbolic algebra on the dimensionality.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div>
Source
<xsd:attributeGroup id="attGp.errorValueArray" name="errorValueArray"><xsd:attribute id="att.errorValueArray" name="errorValueArray" type="errorValueArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of error values.</h:div><h:div class="description">Reports the author's estimate of
the error in an array of values. Only meaningful for
dataTypes mapping to real number.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div>
Source
<xsd:attributeGroup id="attGp.minValueArray" name="minValueArray"><xsd:attribute name="minValueArray" type="floatArrayType" id="att.minValueArray"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated lists of the same length as the array in the parent element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div>
Source
<xsd:attributeGroup id="attGp.maxValueArray" name="maxValueArray"><xsd:attribute name="maxValueArray" type="floatArrayType" id="att.maxValueArray"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum values for numeric _matrix_ or _array.</h:div><h:div class="description">A whitespace-separated list of the same length as the array in the parent element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The end value.</h:div><h:div class="description">The end value in any allowable XSD representation
of data.</h:div>
Source
<xsd:attributeGroup name="end" id="attGp.end"><xsd:attribute name="end" type="xsd:string" id="att.end"><xsd:annotation><xsd:documentation><h:div class="summary">The end value.</h:div><h:div class="description">The end value in any allowable XSD representation
of data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div>
Source
<xsd:attributeGroup id="attGp.delimiter" name="delimiter"><xsd:attribute id="att.delimiter" name="delimiter" type="delimiterType"><xsd:annotation><xsd:documentation><h:div class="summary">A delimiter character for arrays and matrices.</h:div><h:div class="description">By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely:<h:pre>Example:
In the protein database ' CA' and 'CA' are different atom types, and and array could be:
<array delimiter="/" dictRef="pdb:atomTypes">/ N/ CA/CA/ N/</array></h:pre>Note that the array starts and ends with the delimiter, which must be chosen to avoid accidental use. There is currently no syntax for escaping delimiters.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The size of an array or matrix.</h:div>
Source
<xsd:attributeGroup id="attGp.size" name="size"><xsd:attribute id="att.size" name="size" type="sizeType"><xsd:annotation><xsd:documentation><h:div class="summary">The size of an array or matrix.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of matrix.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanis.</h:div>
Source
<xsd:attributeGroup id="attGp.matrixType" name="matrixType"><xsd:attribute name="matrixType" type="matrixType" id="att.matrixType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of matrix.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanis.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The metadata type.</h:div><h:div class="description">This is likely to be the Dublin Core
name or something similar. The use of "type" is an infelicitous
misnomer and we shall try to remove it.</h:div>
Source
<xsd:attributeGroup id="attGp.metadataType" name="metadataType"><!-- Note: name differs from attributeGroup name--><xsd:attribute name="name" type="metadataType" id="att.metadataType"><xsd:annotation><xsd:documentation><h:div class="summary">The metadata type.</h:div><h:div class="description">This is likely to be the Dublin Core
name or something similar. The use of "type" is an infelicitous
misnomer and we shall try to remove it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div>
Source
<xsd:attributeGroup id="attGp.name" name="name"><xsd:attribute id="att.name" name="name" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Name of the object.</h:div><h:div class="description">A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
Source
<xsd:attributeGroup id="attGp.role" name="role"><xsd:attribute id="att.role" name="role" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Role of the object.</h:div><h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The physical state of the substance.</h:div><h:div class="description">No fixed semantics or default.</h:div>
Source
<xsd:attributeGroup id="attGp.state" name="state"><xsd:attribute name="state" type="stateType" id="att.state"><xsd:annotation><xsd:documentation><h:div class="summary">The physical state of the substance.</h:div><h:div class="description">No fixed semantics or default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Constraint on a parameter.</h:div><h:div class="description">Semantics not yet finalised. We anticipate "fixed",
"none" and symbolic relationships to other parameters.</h:div>
Source
<xsd:attributeGroup id="attGp.constraint" name="constraint"><xsd:attribute name="constraint" id="att.constraint" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Constraint on a parameter.</h:div><h:div class="description">Semantics not yet finalised. We anticipate "fixed",
"none" and symbolic relationships to other parameters.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div>
Source
<xsd:attributeGroup id="attGp.type" name="type"><xsd:attribute name="type" id="att.type" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the object.</h:div><h:div class="description">A qualifier which may affect the semantics of the object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A flag on 'arg' to indicate that the value can be substituted.</h:div><h:div class="description">This is still experimental. The value may be an
XPath expression, at present
all attributes (".//@*") are processed. If an attribute contains _ijk_ where the
name of the arg is 'ijk' this string is replaced by the value of ijk,
e.g. if arg with name ijk has a value of 2 then 'm_ijk__z3' becomes
'm2_z3'. substitute="." replaces this element by its value</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.substitute" name="substitute"><xsd:attribute name="substitute" id="att.substitute" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag on 'arg' to indicate that the value can be substituted.</h:div><h:div class="description">This is still experimental. The value may be an
XPath expression, at present
all attributes (".//@*") are processed. If an attribute contains _ijk_ where the
name of the arg is 'ijk' this string is replaced by the value of ijk,
e.g. if arg with name ijk has a value of 2 then 'm_ijk__z3' becomes
'm2_z3'. substitute="." replaces this element by its value</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">parameter name passed to an element</h:div><h:div class="description">This is still experimental.</h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.parameterName" name="parameterName"><xsd:attribute name="parameterName" id="att.parameterName" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">parameter name passed to an element</h:div><h:div class="description">This is still experimental.</h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">raplaces attribute on parent</h:div><h:div class="description">This is still experimental. Creates, overwriting
if necessary, an attribute on parent. Example:<h:pre><foo>
<arg parentAttribute="bar">zubbo</arg></h:pre>will create an attribute bar="zubbo" on <foo></h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.parentAttribute" name="parentAttribute"><xsd:attribute name="parentAttribute" id="att.parentAttribute" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">raplaces attribute on parent</h:div><h:div class="description">This is still experimental. Creates, overwriting
if necessary, an attribute on parent. Example:<h:pre><foo>
<arg parentAttribute="bar">zubbo</arg></h:pre>will create an attribute bar="zubbo" on <foo></h:div><h:div class="summary">2006-06-09: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A flag indicated that the element can detach/delete itself.</h:div><h:div class="description">An element containg this attribute may only have a transient existence
(e.g. a template to create other elements) and this attribute shows that
the element can be deleted at the appropriate stage. The time at which this
is called is application dependent. At present the presence of the attribute
is sufficient to trigger this; later a controlled vocabulary will be developed.</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.delete" name="delete"><xsd:attribute name="delete" id="att.delete" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag indicated that the element can detach/delete itself.</h:div><h:div class="description">An element containg this attribute may only have a transient existence
(e.g. a template to create other elements) and this attribute shows that
the element can be deleted at the appropriate stage. The time at which this
is called is application dependent. At present the presence of the attribute
is sufficient to trigger this; later a controlled vocabulary will be developed.</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A flag on 'arg' to indicate that the value can be calculated.</h:div><h:div class="description">This is still experimental. if eval="_ijk_+3" and
the value of the ijk was 2, this would change the value of the arg to 5.
Only + and - are currently allowed</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.eval" name="eval"><xsd:attribute name="eval" id="att.eval" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A flag on 'arg' to indicate that the value can be calculated.</h:div><h:div class="description">This is still experimental. if eval="_ijk_+3" and
the value of the ijk was 2, this would change the value of the arg to 5.
Only + and - are currently allowed</h:div><h:div class="summary">2006-05-21: PMR added attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a list of atoms.</h:div><h:div class="description">Used by bonds, electrons, atomSets, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRefs" name="atomRefs"><xsd:attribute name="atomRefs" id="att.atomRefs" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a list of atoms.</h:div><h:div class="description">Used by bonds, electrons, atomSets, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a bond.</h:div><h:div class="description">used by electron, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.bondRef" name="bondRef"><xsd:attribute name="bondRef" id="att.bondRef" type="bondRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a bond.</h:div><h:div class="description">used by electron, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a list of bonds.</h:div><h:div class="description">Used by electrons, bondSets, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.bondRefs" name="bondRefs"><xsd:attribute name="bondRefs" id="att.bondRefs" type="bondRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a list of bonds.</h:div><h:div class="description">Used by electrons, bondSets, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div>
Source
<xsd:attributeGroup id="attGp.count" name="count"><xsd:attribute id="att.count" name="count" type="positiveNumberType"><xsd:annotation><xsd:documentation><h:div class="summary">The count of the object.</h:div><h:div class="description">No fixed semantics or default, normally integers.
It is presumed that the element can be multiplied by the count value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRefs4" name="atomRefs4"><xsd:attribute id="att.atomRefs4" name="atomRefs4" type="atomRefs4Type"><xsd:annotation><xsd:documentation><h:div class="summary">A list of 4 references to atoms.</h:div><h:div class="description">Typically used for defining torsions and atomParities,
but could also be used to define a four-centre bond.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of references to atoms.</h:div><h:div class="description">Typical use would be to atoms defining a plane.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRefArray" name="atomRefArray"><xsd:attribute id="att.atomRefArray" name="atomRefArray" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of references to atoms.</h:div><h:div class="description">Typical use would be to atoms defining a plane.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The value of an element with a _convention_.</h:div><h:div class="description">When convention is used this attribute must be present and element content must be empty.</h:div>
Source
<xsd:attributeGroup id="attGp.conventionValue" name="conventionValue"><xsd:attribute name="conventionValue" id="att.conventionValue" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The value of an element with a _convention_.</h:div><h:div class="description">When convention is used this attribute must be present and element content must be empty.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRefs2" name="atomRefs2"><xsd:attribute name="atomRefs2" id="att.atomRefs2" type="atomRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">References to two different atoms.</h:div><h:div class="description">Available for any reference to atoms but normally will be the normal reference attribute on the bond element. The order of atoms is preserved and may matter for some conventions (e.g. wedge/hatch or donor bonds.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
Source
<xsd:attributeGroup id="attGp.order" name="order"><xsd:attribute id="att.order" name="order" type="orderType"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The IDs for an array of bond.</h:div><h:div class="general">Required in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.bondIDArray" name="bondIDArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="bondID" id="att.bondIDArray" type="bondRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The IDs for an array of bond.</h:div><h:div class="general">Required in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The first atoms in each bond.</h:div><h:div class="description">Currently only used in bondArray in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRef1Array" name="atomRef1Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="atomRef1" id="att.atomRef1Array" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The first atoms in each bond.</h:div><h:div class="description">Currently only used in bondArray in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The second atoms in each bond.</h:div><h:div class="general">Only used in bondArray in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.atomRef2Array" name="atomRef2Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="atomRef2" id="att.atomRef2Array" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The second atoms in each bond.</h:div><h:div class="general">Only used in bondArray in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div>
Source
<xsd:attributeGroup id="attGp.orderArray" name="orderArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="order" id="att.orderArray" type="orderArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The order of the bond.</h:div><h:div class="description">There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of a cellParameter.</h:div><h:div class="description">length or angle</h:div>
Source
<xsd:attributeGroup id="attGp.cellParameterType" name="cellParameterType"><!-- Note: name differs from attributeGroup name--><xsd:attribute id="att.cellParameterType" name="type" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The type of a cellParameter.</h:div><h:div class="description">length or angle</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A point group.</h:div><h:div class="description">No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future.</h:div>
Source
<xsd:attributeGroup id="attGp.pointGroup" name="pointGroup"><xsd:attribute id="att.pointGroup" name="pointGroup" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A point group.</h:div><h:div class="description">No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A space group.</h:div><h:div class="description">No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future.</h:div>
Source
<xsd:attributeGroup id="attGp.spaceGroup" name="spaceGroup"><xsd:attribute id="att.spaceGroup" name="spaceGroup" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A space group.</h:div><h:div class="description">No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A symmetry species.</h:div><h:div class="description">No fixed semantics, though we may provide a controlled-extensible list in the future.</h:div>
Source
<xsd:attributeGroup id="attGp.irreducibleRepresentation" name="irreducibleRepresentation"><xsd:attribute name="irreducibleRepresentation" id="att.irreducibleRepresentation" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A symmetry species.</h:div><h:div class="description">No fixed semantics, though we may provide a controlled-extensible list in the future.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div>
Source
<xsd:attributeGroup id="attGp.number" name="number"><xsd:attribute id="att.number" name="number" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">A number determined by context</h:div><h:div class="description">Used for isotope number in isotope, and rotational symmetry number in symmetry for calculation of entropy, etc.</h:div><h:div class="curation">2003-03-30: added number attribut.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The number of molecules per cell.</h:div><h:div class="description">Molecules are defined as the _molecule_ which directly contains the _crystal_ element.</h:div>
Source
<xsd:attributeGroup id="attGp.z" name="z"><xsd:attribute id="att.z" name="z" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">The number of molecules per cell.</h:div><h:div class="description">Molecules are defined as the _molecule_ which directly contains the _crystal_ element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
Source
<xsd:attributeGroup id="attGp.formalCharge" name="formalCharge"><xsd:attribute id="att.formalCharge" name="formalCharge" type="formalChargeType"><xsd:annotation><xsd:documentation><h:div class="summary">The formalCharge on the object.</h:div><h:div class="description">NOT the calculated charge or oxidation state. No formal default, but assumed to be zero if omitted. It may become good practice to include it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A concise formula.</h:div><h:div class="general">The string represents an (unstructured) formula i.e. no submolecules.
Recommended to use the format "H 2 O 1", etc.</h:div>
Source
<xsd:attributeGroup id="attGp.concise" name="concise"><xsd:attribute name="concise" id="att.concise" type="formulaType"><xsd:annotation><xsd:documentation><h:div class="summary">A concise formula.</h:div><h:div class="general">The string represents an (unstructured) formula i.e. no submolecules.
Recommended to use the format "H 2 O 1", etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An inline representation of the object.</h:div><h:div class="general">This can represent a wide range of information from formal serialization
as ASCII through to domain-specific textual representations. It will often be used in conjunction
with the "convention" attribute. For example it could be used to represent IUPAC formula,
SMILES strings, TeX equations, etc. Characters should conforma to the XML character set,
and XML markup (lt and amp) should be escaped.<h:b>IT SHOULD NEVER BE USED FOR INLINE XML</h:b></h:div><h:div class="example" href="attributeGroups/inline.xml"/>
Source
<xsd:attributeGroup id="attGp.inline" name="inline"><xsd:attribute name="inline" id="att.inline" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">An inline representation of the object.</h:div><h:div class="general">This can represent a wide range of information from formal serialization
as ASCII through to domain-specific textual representations. It will often be used in conjunction
with the "convention" attribute. For example it could be used to represent IUPAC formula,
SMILES strings, TeX equations, etc. Characters should conforma to the XML character set,
and XML markup (lt and amp) should be escaped.<h:b>IT SHOULD NEVER BE USED FOR INLINE XML</h:b></h:div><h:div class="example" href="attributeGroups/inline.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div>
Source
<xsd:attributeGroup id="attGp.version" name="version"><xsd:attribute id="att.version" name="version" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">The version of the element</h:div><h:div class="general">cml or identifier elements can currently have
versions. They may be dependent on the date of release and this
attribute is highly recommended. There is no controlled syntax.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Indicates whether the structure is a tautomer.</h:div><h:div class="general">Currently used with IChI _identifier_ element. Semantics, vocabulary and usage are application-dependent.</h:div>
Source
<xsd:attributeGroup id="attGp.tautomeric" name="tautomeric"><xsd:attribute id="att.tautomeric" name="tautomeric" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Indicates whether the structure is a tautomer.</h:div><h:div class="general">Currently used with IChI _identifier_ element. Semantics, vocabulary and usage are application-dependent.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">References to two different molecules.</h:div><h:div class="description">Available for any reference to molecules but
normally will be the normal reference attribute on the join element.
The order of molecules is preserved and may matter.</h:div><h:div class="curation">2006-11-24: PMR created</h:div>
Source
<xsd:attributeGroup id="attGp.moleculeRefs2" name="moleculeRefs2"><xsd:attribute name="moleculeRefs2" id="att.moleculeRefs2" type="moleculeRefs2Type"><xsd:annotation><xsd:documentation><h:div class="summary">References to two different molecules.</h:div><h:div class="description">Available for any reference to molecules but
normally will be the normal reference attribute on the join element.
The order of molecules is preserved and may matter.</h:div><h:div class="curation">2006-11-24: PMR created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Allows a referring element to generate a unique id.</h:div><h:div class="description">idgen can hold a unique identifier which is copied into the id
attribute of the referenced element. This avoids multiple copies of the referenced
object with duplicate ids. EXPERIMENTAL</h:div><h:div class="curation">2006-05-22: PMR added.</h:div>
Source
<xsd:attributeGroup id="attGp.idgen" name="idgen"><xsd:attribute id="att.idgen" name="idgen" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Allows a referring element to generate a unique id.</h:div><h:div class="description">idgen can hold a unique identifier which is copied into the id
attribute of the referenced element. This avoids multiple copies of the referenced
object with duplicate ids. EXPERIMENTAL</h:div><h:div class="curation">2006-05-22: PMR added.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Keyword signifying how object is to be processed.</h:div><h:div class="description">Semantics depend on the parent element</h:div><h:div class="curation">2006-05-20: PMR added</h:div>
Source
<xsd:attributeGroup id="attGp.process" name="process"><xsd:attribute id="att.process" name="process" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Keyword signifying how object is to be processed.</h:div><h:div class="description">Semantics depend on the parent element</h:div><h:div class="curation">2006-05-20: PMR added</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Simple chemical formula.</h:div><h:div class="general">This attribute should only be used for simple formulae (i.e. without brackets or other nesting for which a _formula_ child element should be used. The attribute might be used as a check on the child elements or for ease of representation. Essentially the same as _concise_ attribute on _formula.</h:div>
Source
<xsd:attributeGroup id="attGp.formula" name="formula"><xsd:attribute id="att.formula" name="formula" type="formulaType"><xsd:annotation><xsd:documentation><h:div class="summary">Simple chemical formula.</h:div><h:div class="general">This attribute should only be used for simple formulae (i.e. without brackets or other nesting for which a _formula_ child element should be used. The attribute might be used as a check on the child elements or for ease of representation. Essentially the same as _concise_ attribute on _formula.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div>
Source
<xsd:attributeGroup id="attGp.chirality" name="chirality"><xsd:attribute name="chirality" id="att.chirality" type="chiralityType"><xsd:annotation><xsd:documentation><h:div class="summary">The chirality of a system or molecule.</h:div><h:div class="description">This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div>
Source
<xsd:attributeGroup id="attGp.spinMultiplicity" name="spinMultiplicity"><xsd:attribute id="att.spinMultiplicity" name="spinMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Spin multiplicity.</h:div><h:div class="description">Normally for a molecule. This attribute gives the spin multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value (though values are normally between 1 and 5.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Is the molecule oriented to the symmetry</h:div><h:div class="description">No formal default, but a molecule is assumed to be oriented according to any _symmetry_ children. This is required for crystallographic data, but some systems for isolated molecules allow specification of arbitrary Cartesian or internal coordinates, which must be fitted or refined to a prescribed symmetry. In this case the attribute value is false.</h:div>
Source
<xsd:attributeGroup id="attGp.symmetryOriented" name="symmetryOriented"><xsd:attribute id="att.symmetryOriented" name="symmetryOriented" type="xsd:boolean"><xsd:annotation><xsd:documentation><h:div class="summary">Is the molecule oriented to the symmetry</h:div><h:div class="description">No formal default, but a molecule is assumed to be oriented according to any _symmetry_ children. This is required for crystallographic data, but some systems for isolated molecules allow specification of arbitrary Cartesian or internal coordinates, which must be fitted or refined to a prescribed symmetry. In this case the attribute value is false.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div>
Source
<xsd:attributeGroup id="attGp.x3" name="x3"><xsd:attribute id="att.x3" name="x3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The x coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The provision
for other units is weak at present.) Objects are always described
with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
Source
<xsd:attributeGroup id="attGp.y3" name="y3"><xsd:attribute id="att.y3" name="y3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The y coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div>
Source
<xsd:attributeGroup id="attGp.z3" name="z3"><xsd:attribute id="att.z3" name="z3" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The z coordinate of a 3 dimensional object.</h:div><h:div class="description">The default units are Angstrom. (The
provision for other units is weak at present.) Objects are always
described with a right-handed coordinate system.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.elementType" name="elementType"><xsd:attribute id="att.elementType" name="elementType" type="elementTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Number of hydrogens.</h:div><h:div class="description">The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
Source
<xsd:attributeGroup id="attGp.hydrogenCount" name="hydrogenCount"><xsd:attribute id="att.hydrogenCount" name="hydrogenCount" type="hydrogenCountType"><xsd:annotation><xsd:documentation><h:div class="summary">Number of hydrogens.</h:div><h:div class="description">The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The isotope for an element.</h:div><h:div class="description">A real number describing the isotope. Probably obsolet.</h:div>
Source
<xsd:attributeGroup id="attGp.isotope" name="isotope"><xsd:attribute id="att.isotope" name="isotope" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">The isotope for an element.</h:div><h:div class="description">A real number describing the isotope. Probably obsolet.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The integer number for an isotope.</h:div><h:div class="description">The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef).</h:div>
Source
<xsd:attributeGroup id="attGp.isotopeNumber" name="isotopeNumber"><xsd:attribute id="att.isotopeNumber" name="isotopeNumber" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">The integer number for an isotope.</h:div><h:div class="description">The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef).</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Reference to a fuller description of the isotope.</h:div><h:div class="general">The description may be found in an external collection (e.g. IUPAC) or within the current document.</h:div><h:div class="example" href="isotope2.xml"/>
Source
<xsd:attributeGroup id="attGp.isotopeRef" name="isotopeRef"><xsd:attribute id="att.isotopeRef" name="isotopeRef" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">Reference to a fuller description of the isotope.</h:div><h:div class="general">The description may be found in an external collection (e.g. IUPAC) or within the current document.</h:div><h:div class="example" href="isotope2.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Reference to a description of the isotopic composition of an atom.</h:div><h:div class="description">Used when more than one atom shares the same isotopic composition (e.g. when H/D have been scrambled over some or all of the atoms in a molecule..</h:div><h:div class="example" href="isotope1.xml"/>
Source
<xsd:attributeGroup id="attGp.isotopeListRef" name="isotopeListRef"><xsd:attribute id="att.isotopeListRef" name="isotopeListRef" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">Reference to a description of the isotopic composition of an atom.</h:div><h:div class="description">Used when more than one atom shares the same isotopic composition (e.g. when H/D have been scrambled over some or all of the atoms in a molecule..</h:div><h:div class="example" href="isotope1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Occupancy for an atom.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms.</h:div>
Source
<xsd:attributeGroup id="attGp.occupancy" name="occupancy"><xsd:attribute id="att.occupancy" name="occupancy" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">Occupancy for an atom.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">x2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
Source
<xsd:attributeGroup id="attGp.x2" name="x2"><xsd:attribute name="x2" id="att.x2" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">x2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">y2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2
dimensions. Unrelated to the 3-D coordinates for the object. The
orientation of the axes matters as it can affect the chirality of
object.</h:div>
Source
<xsd:attributeGroup id="attGp.y2" name="y2"><xsd:attribute id="att.y2" name="y2" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">y2 coordinate for an object.</h:div><h:div class="description">Used for displaying the object in 2
dimensions. Unrelated to the 3-D coordinates for the object. The
orientation of the axes matters as it can affect the chirality of
object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.xFract" name="xFract"><xsd:attribute id="att.xFract" name="xFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.yFract" name="yFract"><xsd:attribute id="att.yFract" name="yFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.zFract" name="zFract"><xsd:attribute id="att.zFract" name="zFract" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract
should all be present or absent. If present a _crystal_ element
should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the spaceGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 192. It represents the number of symmetry operations
(without cell translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a spaceGroupMultiplicity of 2.
The spaceGroupMultiplicity can be deduced from a knowledge of the
coordinates and the spaceGroup operators and so is formally redundant but this is a
useful convenience operator. Some crystallographic experiments report this attribute
as, for example, the IUCr CIF item 'atom_site_symmetry_multiplicity'.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
Source
<xsd:attributeGroup id="attGp.spaceGroupMultiplicity" name="spaceGroupMultiplicity"><xsd:attribute id="att.spaceGroupMultiplicity" name="spaceGroupMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the spaceGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 192. It represents the number of symmetry operations
(without cell translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a spaceGroupMultiplicity of 2.
The spaceGroupMultiplicity can be deduced from a knowledge of the
coordinates and the spaceGroup operators and so is formally redundant but this is a
useful convenience operator. Some crystallographic experiments report this attribute
as, for example, the IUCr CIF item 'atom_site_symmetry_multiplicity'.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the pointGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 60 (for icosahedral). It represents the number of symmetry operations
(without any translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a pointGroupMultiplicity of 2.
The pointGroupMultiplicity can be deduced from a knowledge of the
coordinates and the pointGroup operators and so is formally redundant but this is a
useful convenience operator.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div>
Source
<xsd:attributeGroup id="attGp.pointGroupMultiplicity" name="pointGroupMultiplicity"><xsd:attribute id="att.pointGroupMultiplicity" name="pointGroupMultiplicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">SpaceGroup multiplicity.</h:div><h:div class="description">Normally for an atom. This attribute gives the pointGroup multiplicity of the molecule and is independent of any atomic information. No default, and it may take any positive integer value
(though values are normally between 1 and 60 (for icosahedral). It represents the number of symmetry operations
(without any translations) that transform the atom into itself.
Thus an atom on a centre of symmetry can have a pointGroupMultiplicity of 2.
The pointGroupMultiplicity can be deduced from a knowledge of the
coordinates and the pointGroup operators and so is formally redundant but this is a
useful convenience operator.
Distinguish carefully from occupancy which represents incomplete occupation of a
site.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.elementTypeArray" name="elementTypeArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.elementTypeArray" name="elementType" type="elementTypeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">The identity of a chemical element.</h:div><h:div class="description">Normally mandatory on _atom_, _isotope_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of object counts.</h:div><h:div class="description">No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value.</h:div>
Source
<xsd:attributeGroup id="attGp.countArray" name="countArray"><xsd:attribute id="att.countArray" name="count" type="countArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of object counts.</h:div><h:div class="description">No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of formalCharges.</h:div><h:div class="description">Used in CML2 Array mode. NOT the calculated charge or oxidation state. No formal defaults, but assumed to be zero if omitted. It may become good practice to include it.</h:div>
Source
<xsd:attributeGroup id="attGp.formalChargeArray" name="formalChargeArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.formalChargeArray" name="formalCharge" type="formalChargeArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of formalCharges.</h:div><h:div class="description">Used in CML2 Array mode. NOT the calculated charge or oxidation state. No formal defaults, but assumed to be zero if omitted. It may become good practice to include it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">Normally used in CML2 array mode. The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div>
Source
<xsd:attributeGroup id="attGp.hydrogenCountArray" name="hydrogenCountArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.hydrogenCountArray" name="hydrogenCount" type="hydrogenCountArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of hydrogenCounts.</h:div><h:div class="description">Normally used in CML2 array mode. The total number of hydrogens bonded to the atom or molecule. It is preferable to include hydrogens explicitly, and where this is done their count represents the minimum (and may thus override this attribute). It is dangerous to use this attribute for electron-deficient molecules (e.g. diborane) or hydrogen bonds. There is NO DEFAULT and the absence of this attribute must not be given any meaning.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of occupancies.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms.</h:div>
Source
<xsd:attributeGroup id="attGp.occupancyArray" name="occupancyArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.occupancyArray" name="occupancy" type="occupancyArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of occupancies.</h:div><h:div class="description">Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">array of x2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
Source
<xsd:attributeGroup id="attGp.x2Array" name="x2Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="x2" id="att.x2Array" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">array of x2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">array of y2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div>
Source
<xsd:attributeGroup id="attGp.y2Array" name="y2Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.y2Array" name="y2" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">array of y2 coordinate.</h:div><h:div class="description">Normally used in CML2 array mode. Used for displaying the object in 2 dimensions. Unrelated to the 3-D coordinates for the object. The orientation of the axes matters as it can affect the chirality of object.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of x3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.x3Array" name="x3Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.x3Array" name="x3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of x3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of y3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.y3Array" name="y3Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.y3Array" name="y3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of y3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of z3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div>
Source
<xsd:attributeGroup id="attGp.z3Array" name="z3Array"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.z3Array" name="z3" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of z3 coordinate.</h:div><h:div class="summary">Normally used in CML2 array mode.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.xFractArray" name="xFractArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.xFractArray" name="xFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional x coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.yFractArray" name="yFractArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.yFractArray" name="yFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional y coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of fractional z coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div>
Source
<xsd:attributeGroup id="attGp.zFractArray" name="zFractArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.zFractArray" name="zFract" type="coordinateComponentArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of fractional z coordinate.</h:div><h:div class="description">normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An array of atom IDs.</h:div><h:div class="description">Normally an attribute of an array-based element.</h:div>
Source
<xsd:attributeGroup id="attGp.atomIDArray" name="atomIDArray"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="atomID" id="att.atomIDArray" type="atomRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">An array of atom IDs.</h:div><h:div class="description">Normally an attribute of an array-based element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Describes whether child elements are sequential or parallel.</h:div><h:div class="description">There is no default.</h:div>
Source
<xsd:attributeGroup id="attGp.actionOrder" name="actionOrder"><xsd:attribute name="order" id="att.actionOrder" type="actionOrderType"><xsd:annotation><xsd:documentation><h:div class="summary">Describes whether child elements are sequential or parallel.</h:div><h:div class="description">There is no default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div>
Source
<xsd:attributeGroup id="attGp.alternativeType" name="alternativeType"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="type" id="att.alternativeType" type="alternativeTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of an alternative.</h:div><h:div class="general">This adds semantics to an _alternative_ and might be used by an RDF or related engine.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a map providing mappings between atoms</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking atoms. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of atoms are of equal size and have 1:1 mapping between each id. This is another way of saying that the atoms mapped by a given ID are "the same atom".</h:div>
Source
<xsd:attributeGroup id="attGp.atomMap" name="atomMap"><xsd:attribute id="att.atomMap" name="atomMap" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between atoms</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking atoms. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of atoms are of equal size and have 1:1 mapping between each id. This is another way of saying that the atoms mapped by a given ID are "the same atom".</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An atomSet describing the region.</h:div><h:div class="description">Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments.</h:div>
Source
<xsd:attributeGroup id="attGp.atomSetRef" name="atomSetRef"><xsd:attribute name="atomSetRef" type="refType" id="att.atomSetRef"><xsd:annotation><xsd:documentation><h:div class="summary">An atomSet describing the region.</h:div><h:div class="description">Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a map providing mappings between bonds</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking bonds. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of bonds are of equal size and have 1:1 mapping between each id. This is another way of saying that the bonds mapped by a given ID are "the same bond".</h:div>
Source
<xsd:attributeGroup id="attGp.bondMap" name="bondMap"><xsd:attribute id="att.bondMap" name="bondMap" type="xsd:QName"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between bonds</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking bonds. The topology of the linking is defined by the application - it could be overlay of molecular fragments, reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of bonds are of equal size and have 1:1 mapping between each id. This is another way of saying that the bonds mapped by a given ID are "the same bond".</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A parallelipiped box.</h:div><h:div class="description">By default the box uses isometric Cartesians axes but can also be linked to lattice Vector. Any point falling within the box or on a boundary is within the regio.</h:div>
Source
<xsd:attributeGroup id="attGp.box3" name="box3"><xsd:attribute name="box3" type="box3Type" id="att.box3"><xsd:annotation><xsd:documentation><h:div class="summary">A parallelipiped box.</h:div><h:div class="description">By default the box uses isometric Cartesians axes but can also be linked to lattice Vector. Any point falling within the box or on a boundary is within the regio.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The constant to add to the raw data.</h:div><h:div class="description">add *after* applying any multiplier.</h:div>
Source
<xsd:attributeGroup id="attGp.constantToData" name="constantToData"><xsd:attribute id="att.constantToData" name="constantToData" type="xsd:double" default="0.0"><xsd:annotation><xsd:documentation><h:div class="summary">The constant to add to the raw data.</h:div><h:div class="description">add *after* applying any multiplier.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">General formula for the repeat count of the element.</h:div><h:div class="description">Experimental.
No fixed semantics or default.</h:div>
Source
<xsd:attributeGroup id="attGp.countExpression" name="countExpression"><xsd:attribute id="att.countExpression" name="countExpression" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">General formula for the repeat count of the element.</h:div><h:div class="description">Experimental.
No fixed semantics or default.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">default value in an enumeration.</h:div><h:div class="description">A non-whitespace string (value is irrelevant) indicates that the content of this enumeration is the default value (usually of a scalar). It is an error to have more than one default. If the scalar in an instance document has no value (i.e. is empty or contains only whitespace) its value is given by the default. If the scalar in the instance is empty and no enumerations have a default attribute, an application may throw an error.</h:div>
Source
<xsd:attributeGroup id="attGp.default" name="default"><xsd:attribute name="default" type="xsd:string" id="att.default"><xsd:annotation><xsd:documentation><h:div class="summary">default value in an enumeration.</h:div><h:div class="description">A non-whitespace string (value is irrelevant) indicates that the content of this enumeration is the default value (usually of a scalar). It is an error to have more than one default. If the scalar in an instance document has no value (i.e. is empty or contains only whitespace) its value is given by the default. If the scalar in the instance is empty and no enumerations have a default attribute, an application may throw an error.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div>
Source
<xsd:attributeGroup id="attGp.dictionaryPrefix" name="dictionaryPrefix"><xsd:attribute id="att.dictionaryPrefix" name="dictionaryPrefix" type="dictionaryPrefixType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespacePrefix for a data item.</h:div><h:div class="description">The dictionaryPrefix is associated with elements
such as dictionaries and units and allows them to be referenced namespaces.
The dictionaryPrefix is normally unbound but it may be necessary to hardcode them
occasionally. Thus if a value is fixed (e.g. "xsd:double") the prefix must
be identified and fixed.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Dimensionality of a coordinate system.</h:div><h:div class="description">Note that this means that coordinates of higher dimensionality
are ignored or an error is flagged. Thus z3 and dimensionality='2' are incompatible.
At present higher dimensionalities than 3 (cf. Wondratschek) are not supported.
The labelling of the axes id not controlled. ?? should we have an explicit
attribute for labelling convention?.</h:div>
Source
<xsd:attributeGroup id="attGp.dimensionality" name="dimensionality"><xsd:attribute name="dimensionality" id="att.dimensionality" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Dimensionality of a coordinate system.</h:div><h:div class="description">Note that this means that coordinates of higher dimensionality
are ignored or an error is flagged. Thus z3 and dimensionality='2' are incompatible.
At present higher dimensionalities than 3 (cf. Wondratschek) are not supported.
The labelling of the axes id not controlled. ?? should we have an explicit
attribute for labelling convention?.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The basis of the dimension.</h:div><h:div class="description">Normally taken from the seven SI types but possibly expandable.</h:div>
Source
<xsd:attributeGroup id="attGp.dimensionBasis" name="dimensionBasis"><xsd:attribute name="dimensionBasis" type="dimensionType" id="att.dimensionBasis"><xsd:annotation><xsd:documentation><h:div class="summary">The basis of the dimension.</h:div><h:div class="description">Normally taken from the seven SI types but possibly expandable.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The orientation of the eigenvector matrix.</h:div><h:div class="description">Describes whether the vectors are columns or
rows. No default, so effectively mandatory unless you want to make implementers
guess and break applications.</h:div>
Source
<xsd:attributeGroup id="attGp.eigenOrientation" name="eigenOrientation"><!-- Note: name differs from attributeGroup name--><xsd:attribute name="orientation" type="eigenOrientationType" id="att.eigenOrientation"><xsd:annotation><xsd:documentation><h:div class="summary">The orientation of the eigenvector matrix.</h:div><h:div class="description">Describes whether the vectors are columns or
rows. No default, so effectively mandatory unless you want to make implementers
guess and break applications.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a map providing mappings between electrons</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking electrons. The topology of the linking is defined by the application - it could be reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of electrons are of equal size and have 1:1 mapping between each id. This is another way of saying that the electrons mapped by a given ID are "the same electron".</h:div>
Source
<xsd:attributeGroup id="attGp.electronMap" name="electronMap"><xsd:attribute id="att.electronMap" name="electronMap" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a map providing mappings between electrons</h:div><h:div class="description">The map will normally be contained within the same document and referenced by its ID. It will contain a list of links with from and to attributes linking electrons. The topology of the linking is defined by the application - it could be reactant/product mapping, etc. The reserved phrase "USE_IDS" assume that the sets of electrons are of equal size and have 1:1 mapping between each id. This is another way of saying that the electrons mapped by a given ID are "the same electron".</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div>
Source
<xsd:attributeGroup name="endCondition" id="attGp.endCondition"><xsd:attribute name="endCondition" type="xsd:string" id="att.endCondition"><xsd:annotation><xsd:documentation><h:div class="summary">The end condition.</h:div><h:div class="description"><h: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.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Information identifying the name of a file or other resource.</h:div><h:div class="description">This allows an element (such as cml) to carry limited
information about provenance such as the name of the document used to provide the
content. It is not a complete solution but can help to protect a document becoming
separated from its external metadata. It is restricted to the basic XML character set
(printable ANSI) and whitespace (which should anyway be discouraged) is normalized to
single space (attribute values cannot carry newlines).
Quotation marks and other horrors (as used in some OS)
should be avoided.</h:div>
Source
<xsd:attributeGroup id="attGp.fileId" name="fileId"><xsd:attribute id="att.fileId" name="fileId" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Information identifying the name of a file or other resource.</h:div><h:div class="description">This allows an element (such as cml) to carry limited
information about provenance such as the name of the document used to provide the
content. It is not a complete solution but can help to protect a document becoming
separated from its external metadata. It is restricted to the basic XML character set
(printable ANSI) and whitespace (which should anyway be discouraged) is normalized to
single space (attribute values cannot carry newlines).
Quotation marks and other horrors (as used in some OS)
should be avoided.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a functional form.</h:div><h:div class="description">Currently used for potential.</h:div>
Source
<xsd:attributeGroup id="attGp.form" name="form"><xsd:attribute name="form" id="att.form" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a functional form.</h:div><h:div class="description">Currently used for potential.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div>
Source
<xsd:attributeGroup id="attGp.format" name="format"><xsd:attribute id="att.format" name="format" type="formatType"><xsd:annotation><xsd:documentation><h:div class="summary">Format of a spectrum.</h:div><h:div class="description">The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Number of digits after the point.</h:div><h:div class="description">This is used in dictionaries to define precision. However it might be replaced by xsd:facet.</h:div>
Source
<xsd:attributeGroup id="attGp.fractionDigits" name="fractionDigits"><xsd:attribute id="att.fractionDigits" name="fractionDigits" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Number of digits after the point.</h:div><h:div class="description">This is used in dictionaries to define precision. However it might be replaced by xsd:facet.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The base of one or more links.</h:div><h:div class="description">On link elements the value is the single id of an element within the document or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
Source
<xsd:attributeGroup id="attGp.from" name="from"><xsd:attribute id="att.from" name="from" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">The base of one or more links.</h:div><h:div class="description">On link elements the value is the single id of an element within the document or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.fromContext" name="fromContext"><xsd:attribute id="att.fromContext" name="fromContext" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.fromSet" name="fromSet"><xsd:attribute id="att.fromSet" name="fromSet" type="idArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.fromType" name="fromType"><xsd:attribute id="att.fromType" name="fromType" type="xmlElementType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div>
Source
<xsd:attributeGroup id="attGp.ft" name="ft"><xsd:attribute id="att.ft" name="ft" default="none" type="ftType"><xsd:annotation><xsd:documentation><h:div class="summary">Domain of an FT spectrum.</h:div><h:div class="description">Indicates whether a spectrum is raw FID or has been transforme.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div>
Source
<xsd:attributeGroup id="attGp.href" name="href"><xsd:attribute id="att.href" name="href" type="xsd:anyURI"><xsd:annotation><xsd:documentation><h:div class="summary">address of a resource.</h:div><h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef 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.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div>
Source
<xsd:attributeGroup id="attGp.inherit" name="inherit"><xsd:attribute id="att.inherit" name="inherit" type="inheritType"><xsd:annotation><xsd:documentation><h:div class="summary">Inheritance mechanism.</h:div><h:div class="description"><h:p>A reference to an existing element can be used to supplement values such as coordinates. The<h:tt>inheritance</h:tt>attribute determines whether the values are supplemented, overwritten or deleted. In the example:</h:p><h:pre><molecule id="m1" view="initial">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this adds more information -->
<molecule ref="m1" view="initial" inherit="supplement">
<atomArray>
<atom id="a1" hydrogenCount="1"/>
</atomArray>
</molecule>
<!-- this will overwrite the previous values -->
<molecule ref="m1" inherit="overwrite" view="final"
id="m2">
<atomArray>
<atom id="a1" x3="0.1"/>
</atomArray>
</molecule>
<!-- this will delete the previous values -->
<molecule ref="m1" inherit="delete" view="restart">
<atomArray>
<atom id="a1" hydrogenCount=""/>
</atomArray>
</molecule></h:pre><h:p>The first<h:tt>molecule/@ref</h:tt>adds complementary information, the second
changes the values. Software is allowed to generate two independent copies of the molecule and reference them by different IDs (<h:tt>m1</h:tt>and<h:tt>m2</h:tt>).</h:p><h:p>This mechanism is necessary to manage the implied inheritance of partial information during minimisations and dynamics. It requires careful software implementation.</h:p></h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div>
Source
<xsd:attributeGroup id="attGp.integral" name="integral"><xsd:attribute id="att.integral" name="integral" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Area under a peak.</h:div><h:div class="description">Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be use.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">indicates whether a unit is an SI or derived SI unit.</h:div><h:div class="description">required on SI unit elements with value 'true'.
Optional on other units with attribute 'false'. A unitList should contain either
SI units or non-SI units but not both.</h:div>
Source
<xsd:attributeGroup id="attGp.isSI" name="isSI"><xsd:attribute name="isSI" id="att.isSI" type="xsd:boolean"><xsd:annotation><xsd:documentation><h:div class="summary">indicates whether a unit is an SI or derived SI unit.</h:div><h:div class="description">required on SI unit elements with value 'true'.
Optional on other units with attribute 'false'. A unitList should contain either
SI units or non-SI units but not both.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a kpoint.</h:div><h:div class="description">Used by band, etc.</h:div><h:div class="curation">2006-01-21: PMR. Created</h:div>
Source
<xsd:attributeGroup id="attGp.kpointRef" name="kpointRef"><xsd:attribute id="att.kpointRef" name="kpointRef" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a kpoint.</h:div><h:div class="description">Used by band, etc.</h:div><h:div class="curation">2006-01-21: PMR. Created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div>
Source
<xsd:attributeGroup id="attGp.label" name="label"><xsd:attribute name="label" type="xsd:string" id="att.label"><xsd:annotation><xsd:documentation><h:div class="summary">A label.</h:div><h:div class="description">The semantics of label are not defined in the schema but are normally commonly used standard or semi-standard text strings. This attribute has the the same semantics as the more common _label_ element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The primitivity of a lattice.</h:div><h:div class="description">No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency between spacegroups, symmetry operators, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.latticeType" name="latticeType"><xsd:attribute id="att.latticeType" name="latticeType" type="latticeType"><xsd:annotation><xsd:documentation><h:div class="summary">The primitivity of a lattice.</h:div><h:div class="description">No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency between spacegroups, symmetry operators, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Length of a scalar.</h:div><h:div class="description">Probably will be replaced with xsd:schema tool.</h:div>
Source
<xsd:attributeGroup id="attGp.length" name="length"><xsd:attribute id="att.length" name="length" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Length of a scalar.</h:div><h:div class="description">Probably will be replaced with xsd:schema tool.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of the link.</h:div>
Source
<xsd:attributeGroup id="attGp.linkType" name="linkType"><xsd:attribute name="linkType" id="att.linkType" type="linkTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the link.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A list of values.</h:div><h:div class="description">Normally for iterations.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div>
Source
<xsd:attributeGroup name="list" id="attGp.list"><xsd:attribute name="list" type="xsd:string" id="att.list"><xsd:annotation><xsd:documentation><h:div class="summary">A list of values.</h:div><h:div class="description">Normally for iterations.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An attribute providing a mandatory unique ID for an element.</h:div><h:div class="description">This is a horrible hack. It should be possible to add 'required' to
the attributeGroup where used... (Maybe it is and I am still fighting Schema Wars.</h:div>
Source
<xsd:attributeGroup id="attGp.mandatoryId" name="mandatoryId"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.mandatoryId" name="id" type="idType" use="required"><xsd:annotation><xsd:documentation><h:div class="summary">An attribute providing a mandatory unique ID for an element.</h:div><h:div class="description">This is a horrible hack. It should be possible to add 'required' to
the attributeGroup where used... (Maybe it is and I am still fighting Schema Wars.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">maximum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schem.</h:div>
Source
<xsd:attributeGroup id="attGp.maxLength" name="maxLength"><xsd:attribute id="att.maxLength" name="maxLength" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">maximum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schem.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div>
Source
<xsd:attributeGroup id="attGp.measurement" name="measurement"><xsd:attribute id="att.measurement" name="measurement" type="measurementType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of spectral measurement.</h:div><h:div class="description">The nature of the measured data. This is not an exhaustive list and should only be used if it affects the storage or immediate processing.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">minimum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schema.</h:div>
Source
<xsd:attributeGroup id="attGp.minLength" name="minLength"><xsd:attribute id="att.minLength" name="minLength" type="xsd:nonNegativeInteger"><xsd:annotation><xsd:documentation><h:div class="summary">minimum length of a scalar.</h:div><h:div class="description">by analogy with xsd:schema.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to a molecule.</h:div><h:div class="description">Used by spectrum, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.moleculeRef" name="moleculeRef"><xsd:attribute id="att.moleculeRef" name="moleculeRef" type="moleculeRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to a molecule.</h:div><h:div class="description">Used by spectrum, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div>
Source
<xsd:attributeGroup id="attGp.moleculeRefs" name="moleculeRefs"><xsd:attribute name="moleculeRefs" id="att.moleculeRefs" type="moleculeRefArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to one or more molecules.</h:div><h:div class="description">Uses the id attribute as the target identification.
The order of molecules is preserved. It is not necessarily an error to have repeated
references to the same molecule</h:div><h:div class="curation">2005-11-22: PMR. added this attribute.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div>
Source
<xsd:attributeGroup id="attGp.multiplierToData" name="multiplierToData"><xsd:attribute id="att.multiplierToData" name="multiplierToData" type="xsd:double" default="1.0"><xsd:annotation><xsd:documentation><h:div class="summary">The scale by which to multiply raw data or a unit.</h:div><h:div class="description">The scale is applied *before* adding any constant.
The attribute may be found on a data item (scalar, array, matrix, etc.) or
a user-defined unit.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div>
Source
<xsd:attributeGroup id="attGp.namespace" name="namespace"><xsd:attribute id="att.namespace" name="namespace" type="namespaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespace for a data item.</h:div><h:div class="description">The namespace is associated with elements such as dictionaries
and units and allows them to be referenced through free namespace prefixes.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/>
Source
<xsd:attributeGroup id="attGp.parentSI" name="parentSI"><xsd:attribute id="att.parentSI" name="parentSI" type="namespaceRefType"><xsd:annotation><xsd:documentation><h:div class="summary">A dictRef-like reference to the id of the parent SI unit.</h:div><h:div class="description">This parent should occur in this or another dictionary
and be accessible through the dictRef mechanism. This attribute is forbidden
for SI Units themselves. The mechanism holds for base SI units (7) and
all compound (derived) units made by combinations of base Units.</h:div><h:div class="example" href="unit3.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div>
Source
<xsd:attributeGroup id="attGp.peakHeight" name="peakHeight"><xsd:attribute id="att.peakHeight" name="peakHeight" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Height of a peak.</h:div><h:div class="description">For 1-dimensional data
(e.g. y vs x) hould use the same units as the appropriate
axis (e.g. y).</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Multiplicity of a peak.</h:div><h:div class="description">Uses a semi-controlled vocabulary.</h:div>
Source
<xsd:attributeGroup id="attGp.peakMultiplicity" name="peakMultiplicity"><xsd:attribute id="att.peakMultiplicity" name="peakMultiplicity" type="peakMultiplicityType"><xsd:annotation><xsd:documentation><h:div class="summary">Multiplicity of a peak.</h:div><h:div class="description">Uses a semi-controlled vocabulary.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Shape of a peak.</h:div><h:div class="description">Semi-controlled vocabulary such as broad or sharp.</h:div>
Source
<xsd:attributeGroup id="attGp.peakShape" name="peakShape"><xsd:attribute id="att.peakShape" name="peakShape" type="peakShapeType"><xsd:annotation><xsd:documentation><h:div class="summary">Shape of a peak.</h:div><h:div class="description">Semi-controlled vocabulary such as broad or sharp.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of this structure.</h:div><h:div class="description">Semi-controlled vocabulary such as coupling
or splitting.</h:div>
Source
<xsd:attributeGroup id="attGp.peakStructureType" name="peakStructureType"><xsd:attribute id="att.peakStructureType" name="type" type="peakStructureTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of this structure.</h:div><h:div class="description">Semi-controlled vocabulary such as coupling
or splitting.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div>
Source
<xsd:attributeGroup id="attGp.peakUnits" name="peakUnits"><xsd:attribute id="att.peakUnits" name="peakUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for a peak or peak integral.</h:div><h:div class="description">For 2-dimensional spectra the units represent the observation. For an integral they are usually arbitrary and not related to the x- and y- axis units. Thus NMR spectra may use hydrogen count as the units for the peak area.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Is the axis periodic.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or 2D layer. The third vector is orthogonal and represents coordinates normal to the surface. In this case only the direction, not the magnitude of the vector is important.</h:div>
Source
<xsd:attributeGroup id="attGp.periodic" name="periodic"><xsd:attribute name="periodic" type="xsd:boolean" id="att.periodic" default="true"><xsd:annotation><xsd:documentation><h:div class="summary">Is the axis periodic.</h:div><h:div class="description">Any or all of the axes may be periodic or aperiodic. An example could be a surface where 2 periodic axes (not necessarily orthogonal) are used to describe the coordinates in the surface, perhaps representing lattice vectors of a 3D crystal or 2D layer. The third vector is orthogonal and represents coordinates normal to the surface. In this case only the direction, not the magnitude of the vector is important.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Periodicity of the system.</h:div><h:div class="summary">This represents the number of dimensions (or coordinate axes) along periodic behaviour occurs and can be supported by symmetry operators or other transformations. Periodicity must never exceed dimensionality.</h:div>
Source
<xsd:attributeGroup id="attGp.periodicity" name="periodicity"><xsd:attribute name="periodicity" id="att.periodicity" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">Periodicity of the system.</h:div><h:div class="summary">This represents the number of dimensions (or coordinate axes) along periodic behaviour occurs and can be supported by symmetry operators or other transformations. Periodicity must never exceed dimensionality.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A point in 3 dimensions.</h:div><h:div class="description">can be used for any complex
geometrical object, such as line.</h:div>
Source
<xsd:attributeGroup id="attGp.point3" name="point3"><xsd:attribute name="point3" type="point3Type" id="att.point3"><xsd:annotation><xsd:documentation><h:div class="summary">A point in 3 dimensions.</h:div><h:div class="description">can be used for any complex
geometrical object, such as line.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
Source
<xsd:attributeGroup id="attGp.power" name="power"><xsd:attribute name="power" type="xsd:double" id="att.power"><xsd:annotation><xsd:documentation><h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div>
Source
<xsd:attributeGroup id="attGp.powerRequired" name="powerRequired"><!-- this is awful - but I can't find how to add required otherwise --><xsd:attribute name="power" type="xsd:double" use="required" id="att.powerRequired"><xsd:annotation><xsd:documentation><h:div class="summary">The power to which a dimension should be raised.</h:div><h:div class="description">Normally an integer. Must be included, even if unity.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div>
Source
<xsd:attributeGroup id="attGp.preserve" name="preserve"><xsd:attribute name="preserve" type="xsd:boolean" id="att.preserve"><xsd:annotation><xsd:documentation><h:div class="summary">Is the dimension preserved during algebra.</h:div><h:div class="dimension">Experimental. The idea is to support
concepts like volume/volume where algebraically these cancel out.
preserve="yes" is intending to support preservation during
derivation of new unitTypes.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A ratio in the range 0 to 1.</h:div><h:div class="description">Currently used for ratios between brached reactions but re-usable for other concepts.</h:div>
Source
<xsd:attributeGroup id="attGp.ratio" name="ratio"><xsd:attribute name="ratio" id="att.ratio" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">A ratio in the range 0 to 1.</h:div><h:div class="description">Currently used for ratios between brached reactions but re-usable for other concepts.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div>
Source
<xsd:attributeGroup id="attGp.reactionFormat" name="reactionFormat"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.reactionFormat" name="format" type="reactionFormatType"><xsd:annotation><xsd:documentation><h:div class="summary">Format of the reaction component.</h:div><h:div class="description">Indicates how the components of reactionScheme, reactionStepList, etc. should be processed. No controlled vocabulary. One example is format="cmlSnap" asserts that the processor can assume that the reactants and products can be rendered using the CMLSnap design. Note that the reaction can be interpreted without reference to the format, which is primarily a processing instruction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Role of the reaction.</h:div>
Source
<xsd:attributeGroup id="attGp.reactionRole" name="reactionRole"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="role" id="att.reactionRole" type="reactionRoleType"><xsd:annotation><xsd:documentation><h:div class="summary">Role of the reaction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div>
Source
<xsd:attributeGroup id="attGp.reactionStepListType" name="reactionStepListType"><!-- Note: name differs from attributeGroup name --><xsd:attribute name="type" id="att.reactionStepListType" default="consecutive" type="reactionStepListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionStepList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div><h:div>The semantic of these are not fully explored, but we suggest that consecutive and simultaneous should be the first to be supported</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of the reaction.</h:div>
Source
<xsd:attributeGroup id="attGp.reactionType" name="reactionType"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.reactionType" name="type" type="reactionTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the reaction.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A list of regions creating a union.</h:div><h:div class="description">The union of a series of regions produces a larger region (possibly disjoint). Any point belonging to any of the referenced regions is a member of this region.</h:div>
Source
<xsd:attributeGroup id="attGp.regionRefs" name="regionRefs"><xsd:attribute name="regionRefs" type="refType" id="att.regionRefs"><xsd:annotation><xsd:documentation><h:div class="summary">A list of regions creating a union.</h:div><h:div class="description">The union of a series of regions produces a larger region (possibly disjoint). Any point belonging to any of the referenced regions is a member of this region.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div>
Source
<xsd:attributeGroup id="attGp.relatedEntryType" name="relatedEntryType"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.relatedEntryType" name="type" type="relatedEntryTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of relatedEntry.</h:div><h:div class="description">Type represents a the type of relationship in a relatedEntry element.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div>
Source
<xsd:attributeGroup id="attGp.scheme" name="scheme"><xsd:attribute name="scheme" id="att.reactionStepList.scheme" default="sequence" type="schemeType"><xsd:annotation><xsd:documentation><h:div class="summary">The sequence of steps in a reactionList.</h:div><h:div class="description">By default the reactions in a reactionStepList are assumed to take place in sequence (e.g. one or more products of reaction n are used in reaction n+1 or later. However there are cases where it is known that reactions take place in parallel (e.g. if there is no overlap of molecular identities). Alternatively there are points at which there are two or more competing reactions which may depend on conditions or concentrations. A small semi-controlled vocabulary is suggested.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Serial number or other id.</h:div><h:div class="summary">Currently only on module. Modules with the same _role_ attribute can be distinguished by _serial_. This is often an integer but other schemes may be used.</h:div>
Source
<xsd:attributeGroup id="attGp.serial" name="serial"><xsd:attribute name="serial" id="att.serial" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Serial number or other id.</h:div><h:div class="summary">Currently only on module. Modules with the same _role_ attribute can be distinguished by _serial_. This is often an integer but other schemes may be used.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">shape of object.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanism.</h:div>
Source
<xsd:attributeGroup id="attGp.shape" name="shape"><xsd:attribute name="shape" type="shapeType" id="att.shape"><xsd:annotation><xsd:documentation><h:div class="summary">shape of object.</h:div><h:div class="description">Mainly square, but extensible through the _xsd:union_ mechanism.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div>
Source
<xsd:attributeGroup id="attGp.siNamespace" name="siNamespace"><xsd:attribute id="att.siNamespace" name="siNamespace" type="namespaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The namespace for SI Units dictionary.</h:div><h:div class="description">Main use is on unitList to identify the
dictionary holding the SI Units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Array of namespaces locating SI Units dictionaries.</h:div><h:div class="description">Main use is on unitList to identify the
dictionaries holding the SI Units.</h:div>
Source
<xsd:attributeGroup id="attGp.siNamespaceArray" name="siNamespaceArray"><xsd:attribute id="att.siNamespaceArray" name="siNamespaceArray" type="namespaceArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">Array of namespaces locating SI Units dictionaries.</h:div><h:div class="description">Main use is on unitList to identify the
dictionaries holding the SI Units.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The spaceType of the lattice.</h:div><h:div class="description">Usually real or reciprocal. No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency for unitTypes, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.spaceType" name="spaceType"><xsd:attribute id="att.spaceType" name="spaceType" type="spaceType"><xsd:annotation><xsd:documentation><h:div class="summary">The spaceType of the lattice.</h:div><h:div class="description">Usually real or reciprocal. No default. The semantics of this are software-dependent (i.e. this Schema does not check for consistency for unitTypes, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of the spectrum.</h:div>
Source
<xsd:attributeGroup id="attGp.spectrumType" name="spectrumType"><xsd:attribute name="type" id="att.spectrumType" type="spectrumTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the spectrum.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A sphere.</h:div><h:div class="description">Currently describes a region. Any point falling within the sphere or on its surface is within the region.</h:div>
Source
<xsd:attributeGroup id="attGp.sphere3" name="sphere3"><xsd:attribute name="sphere3" type="sphere3Type" id="att.sphere3"><xsd:annotation><xsd:documentation><h:div class="summary">A sphere.</h:div><h:div class="description">Currently describes a region. Any point falling within the sphere or on its surface is within the region.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The spin of a system.</h:div><h:div class="description">Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope.</h:div><h:div class="example" href="spin1.xml"/>
Source
<xsd:attributeGroup id="attGp.spin" name="spin"><xsd:attribute id="att.spin" name="spin" type="isotopicSpinType"><xsd:annotation><xsd:documentation><h:div class="summary">The spin of a system.</h:div><h:div class="description">Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope.</h:div><h:div class="example" href="spin1.xml"/></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div>
Source
<xsd:attributeGroup name="startCondition" id="attGp.startCondition"><xsd:attribute name="startCondition" type="xsd:string" id="att.startCondition"><xsd:annotation><xsd:documentation><h:div class="summary">The start condition.</h:div><h:div class="description">This can describe the condition(s) that has to be met before an action can begin, such as in a recipe. Semantics are unexplored but could be used to control robotic operations.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div>
Source
<xsd:attributeGroup id="attGp.substanceListType" name="substanceListType"><!-- Note: name differs from attributeGroup name --><xsd:attribute id="att.substanceListType" name="type" type="substanceListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">Type of the substanceList.</h:div><h:div class="description">Extension is allowed through the "other" value.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div>
Source
<xsd:attributeGroup id="attGp.symbol" name="symbol"><xsd:attribute name="symbol" id="att.symbol" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">A symbol.</h:div><h:div class="description">No semantics. However it should contain only
ASCII characters and we may have to develop an escaping mechanism.
Used on _atomicBasisFunction_, _unit_, etc.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A term in a dictionary.</h:div><h:div class="description">The term should be a noun or nounal phrase, with a separate definition and further description.</h:div>
Source
<xsd:attributeGroup id="attGp.term" name="term"><xsd:attribute id="att.term" name="term" type="xsd:string" use="required"><xsd:annotation><xsd:documentation><h:div class="summary">A term in a dictionary.</h:div><h:div class="description">The term should be a noun or nounal phrase, with a separate definition and further description.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The test condition on an if element.</h:div><h:div class="description">No controlled format yet.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div>
Source
<xsd:attributeGroup name="test" id="attGp.test"><xsd:attribute name="test" type="xsd:string" id="att.test"><xsd:annotation><xsd:documentation><h:div class="summary">The test condition on an if element.</h:div><h:div class="description">No controlled format yet.</h:div><h:div class="curation">2006-06-09: PMR Created..</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The target of one or more links.</h:div><h:div class="summary">On link elements the value is the single id of an element within the document or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div>
Source
<xsd:attributeGroup id="attGp.to" name="to"><xsd:attribute id="att.to" name="to" type="refType"><xsd:annotation><xsd:documentation><h:div class="summary">The target of one or more links.</h:div><h:div class="summary">On link elements the value is the single id of an element within the document or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div><h:div class="curation">2005-06-18: updated docs</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.toContext" name="toContext"><xsd:attribute id="att.toContext" name="toContext" type="idType"><xsd:annotation><xsd:documentation><h:div class="summary">The context for the 'from' links in a map.</h:div><h:div class="description"><h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a document. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p><h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.toSet" name="toSet"><xsd:attribute id="att.toSet" name="toSet" type="idArrayType"><xsd:annotation><xsd:documentation><h:div class="summary">A set of ids representing the base of a link.</h:div><h:div class="description"><h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">total digits in a scalar.</h:div><h:div class="description">based on xsd:schema.</h:div>
Source
<xsd:attributeGroup id="attGp.totalDigits" name="totalDigits"><xsd:attribute id="att.totalDigits" name="totalDigits" type="xsd:positiveInteger"><xsd:annotation><xsd:documentation><h:div class="summary">total digits in a scalar.</h:div><h:div class="description">based on xsd:schema.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div>
Source
<xsd:attributeGroup id="attGp.toType" name="toType"><xsd:attribute id="att.toType" name="toType" type="xmlElementType"><xsd:annotation><xsd:documentation><h:div class="summary">The type of the base of a link.</h:div><h:div class="description"><h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p><h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p></h:div><h:div class="curation">2005-06-18: created</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Needed to differentiate the rather unhappy
polymorphism of unitList/unit and unitList/unitType.</h:div><h:div class="curation">2005-12-17 PMR: Added</h:div>
Source
<xsd:attributeGroup id="attGp.unitListType" name="unitListType"><xsd:attribute id="att.unitListType" name="type" type="unitListTypeType"><xsd:annotation><xsd:documentation><h:div class="summary">A reference to the type of a unit.</h:div><h:div class="description">Needed to differentiate the rather unhappy
polymorphism of unitList/unit and unitList/unitType.</h:div><h:div class="curation">2005-12-17 PMR: Added</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">A vector in 3 dimensions.</h:div><h:div class="description">can be used for any complex geometrical object,
such as line.</h:div>
Source
<xsd:attributeGroup id="attGp.vector3" name="vector3"><xsd:attribute name="vector3" type="vector3Type" id="att.vector3"><xsd:annotation><xsd:documentation><h:div class="summary">A vector in 3 dimensions.</h:div><h:div class="description">can be used for any complex geometrical object,
such as line.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div>
Source
<xsd:attributeGroup id="attGp.weight" name="weight"><xsd:attribute name="weight" type="xsd:double" id="att.weight"><xsd:annotation><xsd:documentation><h:div class="summary">Weight of the element.</h:div><h:div class="description">Currently the weight of the kPoint, derived from the symmetry such as the inverse of the multiplicity in real space. Thus a point at 0,0,0 in monoclinic space might be 0.25. The lowest value possible is probably 1/48.0 (in m3m).</h:div><h:div class="curation">2003-09-15 (added at suggestion of Jon Wakelin).</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Whitespace.</h:div><h:div class="description">Attached to entry. This may be obsolete.</h:div>
Source
<xsd:attributeGroup id="attGp.whiteSpace" name="whiteSpace"><xsd:attribute id="att.whiteSpace" name="whiteSpace" type="xsd:string"><xsd:annotation><xsd:documentation><h:div class="summary">Whitespace.</h:div><h:div class="description">Attached to entry. This may be obsolete.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div>
Source
<xsd:attributeGroup id="attGp.xMax" name="xMax"><xsd:attribute id="att.xMax" name="xMax" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum xValue.</h:div><h:div class="description">Annotates x-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMin_ attribute but if so xMax should be greater than or
equals to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div>
Source
<xsd:attributeGroup id="attGp.xMin" name="xMin"><xsd:attribute id="att.xMin" name="xMin" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum xValue.</h:div><h:div class="description">Annotates x-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses xUnits or the same units as the data. There may or may not
be a _xMax_ attribute but if so xMin should be less than or equals
to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div>
Source
<xsd:attributeGroup id="attGp.xUnits" name="xUnits"><xsd:attribute id="att.xUnits" name="xUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for x axis.</h:div><h:div class="description">All x-axis data must have unambiguous units. Ideally the data and _xMin_ or _xValue_ should share the same units but different xUnits can be used as long as it is clear..</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div>
Source
<xsd:attributeGroup id="attGp.xValue" name="xValue"><xsd:attribute id="att.xValue" name="xValue" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Value along an x axis.</h:div><h:div class="description">Annotates x-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses xUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div>
Source
<xsd:attributeGroup id="attGp.xWidth" name="xWidth"><xsd:attribute id="att.xWidth" name="xWidth" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">An unsigned interval along an x axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
xUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div>
Source
<xsd:attributeGroup id="attGp.yield" name="yield"><xsd:attribute name="yield" id="att.yield" type="occupancyType"><xsd:annotation><xsd:documentation><h:div class="summary">Yield of a reaction or reactionStep.</h:div><h:div class="description">Yields can be given on either element. They should lie in the range 0 to 1 inclusive (i.e. percentages will need to be converted). Software may use yield to calculate amounts of substances created during a reaction or series of reactions.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div>
Source
<xsd:attributeGroup id="attGp.yMax" name="yMax"><xsd:attribute id="att.yMax" name="yMax" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Maximum yValue.</h:div><h:div class="description">Annotates y-axis data with a maximum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may not
be a _yMin_ attribute but if so yMax should be greater than or
equals to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div>
Source
<xsd:attributeGroup id="attGp.yMin" name="yMin"><xsd:attribute id="att.yMin" name="yMin" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Minimum yValue.</h:div><h:div class="description">Annotates y-axis data with a minimum
value. This need not be algorithmically deducible from the data
and is typically used for the extent of a _peak_ or _peakGroup_.
It uses yUnits or the same units as the data. There may or may
not be a _yMax_ attribute but if so yMin should be less than or
equal to it.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div>
Source
<xsd:attributeGroup id="attGp.yUnits" name="yUnits"><xsd:attribute id="att.yUnits" name="yUnits" type="unitsType"><xsd:annotation><xsd:documentation><h:div class="summary">Units for y axis.</h:div><h:div class="description">All y-axis data must have unambiguous units. Ideally the data and _yMin_ or _yValue_ should share the same units but different yUnits can be used as long as it is clear.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div>
Source
<xsd:attributeGroup id="attGp.yValue" name="yValue"><xsd:attribute id="att.yValue" name="yValue" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">Value along a y axis.</h:div><h:div class="description">Annotates y-axis data with a value. It
is typically used for the location of a _peak_ or _peakGroup_. It
uses yUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
<h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div>
Source
<xsd:attributeGroup id="attGp.yWidth" name="yWidth"><xsd:attribute id="att.yWidth" name="yWidth" type="xsd:double"><xsd:annotation><xsd:documentation><h:div class="summary">An unsigned interval along a y axis.</h:div><h:div class="description">It is typically used for the width of
a _peak_ or _peakGroup_ but could be used for any range. It uses
yUnits or the same units as the data.</h:div></xsd:documentation></xsd:annotation></xsd:attribute></xsd:attributeGroup>
