symmetry 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.
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.
The element may also be used to give a label for the symmetry species (irreducible representation) such as "A1u" for a vibration or orbital.
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>.
The default convention for point group symmetry is Schoenflies and for spacegroups is "H-M". Other conventions (e.g. "Hall") must be specfied through the convention attribute.
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 symmetryOriented for this purpose.
<symmetry pointGroup="C2v" id="s1">
<stm:matrix id="e" rows="3" columns="3">
1 0 0
0 1 0
0 0 1
</stm:matrix>
<stm:matrix id="c2" rows="3" columns="3">
-1 0 0
0 -1 0
0 0 1
</stm:matrix>
<stm:matrix id="sx" rows="3" columns="3">
-1 0 0
0 1 0
0 0 1
</stm:matrix>
<stm:matrix id="sy" rows="3" columns="3">
1 0 0
0 -1 0
0 0 1
</stm:matrix>
</symmetry>
The namespace is optional but recommended where possible
Note: this convention is only used within STMML and related languages; it is NOT a generic URI.
<list>
<!-- dictRef is of namespaceRefType -->
<scalar dictRef="chem:mpt">123</scalar>
<!-- error -->
<scalar dictRef="mpt23">123</scalar>
</list>
A reference to a dictionary entry.
Elements in data instances such as scalar may have a dictRef 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.
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.
This attribute can also be used on dictionary elements to define the namespace prefix
<scalar dataType="xsd:float" title="surfaceArea"
dictRef="cmlPhys:surfArea"
xmlns:cmlPhys="http://www.xml-cml.org/dict/physical"
units="units:cm2">50</scalar>
<stm:list xmlns:stm="http://www.xml-cml.org/schema/stmml">
<stm:observation>
<p>We observed <object count="3" dictRef="#p1"/>
constructing dwellings of different material</p>
</stm:observation>
<stm:entry id="p1" term="pig">
<stm:definition>A domesticated animal.</stm:definition>
<stm:description>Predators include wolves</stm:description>
<stm:description class="scientificName">Sus scrofa</stm:description>
</stm:entry>
</stm:list>
The namespace is optional but recommended where possible
Note: this convention is only used within STMML and related languages; it is NOT a generic URI.
<list>
<!-- dictRef is of namespaceRefType -->
<scalar dictRef="chem:mpt">123</scalar>
<!-- error -->
<scalar dictRef="mpt23">123</scalar>
</list>
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 molecule would by default extend to its bond and atom children. This can be overwritten if necessary by an explicit convention.
It may be useful to create conventions with namespaces (e.g. iupac:name). Use of convention will normally require non-STMML semantics, and should be used with caution. We would expect that conventions prefixed with "ISO" would be useful, such as ISO8601 for dateTimes.
There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.
<bond convention="fooChem" order="-5" xmlns:fooChem="http://www.fooChem/conventions"/>
<action title="turn on heat" start="T09:00:00" convention="xsd"/>
This is not formally of type ID (an XML NAME which must start with a letter and contain only letters, digits and .-_:). It is recommended that IDs start with a letter, and contain no punctuation or whitespace. The function generate-id() in XSLT will generate semantically void unique IDs.
It is difficult to ensure uniqueness when documents are merged. We suggest namespacing IDs, perhaps using the containing elements as the base. Thus mol3:a1 could be a useful unique ID. However this is still experimental.