| pos | elem | att | summary | desc |
|---|---|---|---|---|
| 1 | abundance | title | A title on an element. | No controlled value. |
| 2 | abundance | id | An attribute providing a unique ID for an element. | |
| 3 | abundance | convention | A reference to a convention. | 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. |
| 4 | abundance | dictRef | 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 |
| 5 | abundance | min | The minimum value allowed for an element or attribute. | |
| 6 | abundance | max | Maximum value allowed for an element or attribute. | |
| 7 | abundance | units | Scientific units on an element. | 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. |
| 8 | action | title | A title on an element. | No controlled value. |
| 9 | action | id | An attribute providing a unique ID for an element. | |
| 10 | action | convention | A reference to a convention. | 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. |
| 11 | action | dictRef | 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 |
| 12 | action | actionGroup | The start time. | The start time in any allowable XSD representation of date, time or dateTime. This will normally be a clock time or date. |
| 13 | action | ref | A reference to an element of given type. | ref 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. |
| 14 | action | type | Type of the object | A qualifier which may affect the semantics of the object |
| 15 | actionList | title | A title on an element. | No controlled value. |
| 16 | actionList | id | An attribute providing a unique ID for an element. | |
| 17 | actionList | convention | A reference to a convention. | 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. |
| 18 | actionList | dictRef | 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 |
| 19 | actionList | actionGroup | The start time. | The start time in any allowable XSD representation of date, time or dateTime. This will normally be a clock time or date. |
| 20 | actionList | type | Type of the object | A qualifier which may affect the semantics of the object |
| 21 | actionList | actionOrder | Describes whether child elements are sequential or parallel. There is no default. | |
| 22 | alternative | id | An attribute providing a unique ID for an element. | |
| 23 | alternative | convention | A reference to a convention. | 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. |
| 24 | alternative | alternativeType | The type of an alternative | |
| 25 | amount | title | A title on an element. | No controlled value. |
| 26 | amount | id | An attribute providing a unique ID for an element. | |
| 27 | amount | convention | A reference to a convention. | 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. |
| 28 | amount | dictRef | 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 |
| 29 | amount | units | Scientific units on an element. | 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. |
| 30 | angle | title | A title on an element. | No controlled value. |
| 31 | angle | id | An attribute providing a unique ID for an element. | |
| 32 | angle | convention | A reference to a convention. | 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. |
| 33 | angle | dictRef | 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 |
| 34 | angle | atomRefs3 | A list of three references to atoms. | Typically used for defining angles, but could also be used to define a three-centre bond. |
| 35 | angle | angleUnits | Restricts units to radians or degrees. | |
| 36 | angle | errorValue | Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 37 | angle | errorBasis | Basis of the error estimate | |
| 38 | angle | min | The minimum value allowed for an element or attribute. | |
| 39 | angle | max | Maximum value allowed for an element or attribute. | |
| 40 | angle | ref | A reference to an element of given type. | ref 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. |
| 41 | appinfo | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 42 | arg | title | A title on an element. | No controlled value. |
| 43 | arg | id | An attribute providing a unique ID for an element. | |
| 44 | arg | convention | A reference to a convention. | 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. |
| 45 | arg | dictRef | 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 |
| 46 | arg | ref | A reference to an element of given type. | ref 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. |
| 47 | arg | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 48 | arg | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 49 | array | title | A title on an element. | No controlled value. |
| 50 | array | id | An attribute providing a unique ID for an element. | |
| 51 | array | convention | A reference to a convention. | 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. |
| 52 | array | dictRef | 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 |
| 53 | array | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 54 | array | errorValueArray | Array of error values | Reports the author's estimate of the error in an array of values. Only meaningful for dataTypes mapping to real numbers |
| 55 | array | errorBasis | Basis of the error estimate | |
| 56 | array | minValueArray | Minimum values for numeric _matrix_ or _array_ | A whitespace-separated lists of the same length as the array in the parent element |
| 57 | array | maxValueArray | Maximum values for numeric _matrix_ or _array_ | A whitespace-separated list of the same length as the array in the parent element |
| 58 | array | units | Scientific units on an element. | 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. |
| 59 | array | delimiter | A delimiter character for arrays and matrices. | By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely: 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> 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. |
| 60 | array | size | The size of an array or matrix | |
| 61 | array | ref | A reference to an element of given type. | ref 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. |
| 62 | atom | id | An attribute providing a unique ID for an element. | |
| 63 | atom | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 64 | atom | elementType | The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 65 | atom | formalCharge | The formalCharge on the object | 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. |
| 66 | atom | hydrogenCount | Number of hydrogens | 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. |
| 67 | atom | isotope | The isotope for an element | A real number describing the isotope. Probably obsolete |
| 68 | atom | isotopeNumber | The integer number for an isotope. | The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef). |
| 69 | atom | isotopeRef | Reference to a fuller description of the isotope. | |
| 70 | atom | isotopeListRef | Reference to a description of the isotopic composition of an atom. | |
| 71 | atom | occupancy | Occupancy for an atom | Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms. |
| 72 | atom | xy2 | x2 coordinate for an object | 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 objects |
| 73 | atom | xyz3 | group of attributes for arrays of x3 y3 z3 | |
| 74 | atom | xyzFract | group of attributes for xFract yFract zFract | normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur. |
| 75 | atom | title | A title on an element. | No controlled value. |
| 76 | atom | convention | A reference to a convention. | 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. |
| 77 | atom | dictRef | 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 |
| 78 | atom | ref | A reference to an element of given type. | ref 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. |
| 79 | atom | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 80 | atomArray | title | A title on an element. | No controlled value. |
| 81 | atomArray | id | An attribute providing a unique ID for an element. | |
| 82 | atomArray | convention | A reference to a convention. | 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. |
| 83 | atomArray | dictRef | 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 |
| 84 | atomArray | elementTypeArray | The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 85 | atomArray | countArray | Array of object counts | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 86 | atomArray | formalChargeArray | An array of formalCharges | 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. |
| 87 | atomArray | hydrogenCountArray | Array of hydrogenCounts | 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. |
| 88 | atomArray | occupancyArray | Array of occupancies | Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms. |
| 89 | atomArray | xy2Array | array of x2 coordinates | 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 objects |
| 90 | atomArray | xyz3Array | group of attributes for arrays of x3 y3 z3 | |
| 91 | atomArray | xyzFractArray | group of attributes for arrays of xFract yFract zFract | normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur. |
| 92 | atomArray | atomIDArray | An array of atomIDs | Normally an attribute of an array-based element |
| 93 | atomArray | ref | A reference to an element of given type. | ref 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. |
| 94 | atomicBasisFunction | atomRef | A reference to an atom. | Used by bond, electron, etc. |
| 95 | atomicBasisFunction | title | A title on an element. | No controlled value. |
| 96 | atomicBasisFunction | id | An attribute providing a unique ID for an element. | |
| 97 | atomicBasisFunction | convention | A reference to a convention. | 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. |
| 98 | atomicBasisFunction | dictRef | 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 |
| 99 | atomicBasisFunction | n | Principal quantum number | 1, 2, 3, etc. |
| 100 | atomicBasisFunction | l | Secondary quantum number | 0, 1, etc. |
| 101 | atomicBasisFunction | m | Azimuthal quantum number | -1, 0, 1, etc. |
| 102 | atomicBasisFunction | symbol | A symbol | Currently only used on _atomicBasisFunction_. Example "s" |
| 103 | atomicBasisFunction | lm | symbolic represention of l amd m | s, p, px, dxy, dx2y2, f, etc. |
| 104 | atomParity | title | A title on an element. | No controlled value. |
| 105 | atomParity | id | An attribute providing a unique ID for an element. | |
| 106 | atomParity | convention | A reference to a convention. | 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. |
| 107 | atomParity | dictRef | 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 |
| 108 | atomParity | atomRefs4 | A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 109 | atomSet | title | A title on an element. | No controlled value. |
| 110 | atomSet | id | An attribute providing a unique ID for an element. | |
| 111 | atomSet | convention | A reference to a convention. | 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. |
| 112 | atomSet | dictRef | 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 |
| 113 | atomSet | size | The size of an array or matrix | |
| 114 | atomType | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 115 | atomType | atomRef | A reference to an atom. | Used by bond, electron, etc. |
| 116 | atomType | title | A title on an element. | No controlled value. |
| 117 | atomType | id | An attribute providing a unique ID for an element. | |
| 118 | atomType | convention | A reference to a convention. | 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. |
| 119 | atomType | dictRef | 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 |
| 120 | atomTypeList | dictRef | 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 |
| 121 | atomTypeList | convention | A reference to a convention. | 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. |
| 122 | atomTypeList | title | A title on an element. | No controlled value. |
| 123 | atomTypeList | id | An attribute providing a unique ID for an element. | |
| 124 | atomTypeList | ref | A reference to an element of given type. | ref 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. |
| 125 | band | kpoint | The k vector | The k-vector with 3 components |
| 126 | band | weight | Weight of the element | 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). |
| 127 | band | label | A label | 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 |
| 128 | band | title | A title on an element. | No controlled value. |
| 129 | band | id | An attribute providing a unique ID for an element. | |
| 130 | band | convention | A reference to a convention. | 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. |
| 131 | band | dictRef | 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 |
| 132 | bandList | title | A title on an element. | No controlled value. |
| 133 | bandList | id | An attribute providing a unique ID for an element. | |
| 134 | bandList | convention | A reference to a convention. | 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. |
| 135 | bandList | dictRef | 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 |
| 136 | basisSet | dictRef | 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 |
| 137 | basisSet | convention | A reference to a convention. | 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. |
| 138 | basisSet | title | A title on an element. | No controlled value. |
| 139 | basisSet | id | An attribute providing a unique ID for an element. | |
| 140 | basisSet | ref | A reference to an element of given type. | ref 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. |
| 141 | basisSet | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 142 | bond | title | A title on an element. | No controlled value. |
| 143 | bond | id | An attribute providing a unique ID for an element. | |
| 144 | bond | convention | A reference to a convention. | 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. |
| 145 | bond | dictRef | 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 |
| 146 | bond | ref | A reference to an element of given type. | ref 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. |
| 147 | bond | atomRefs2 | References to two different atoms | 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) |
| 148 | bond | atomRefs | A reference to a list of atoms. | Used by bonds, electrons, atomSets, etc. |
| 149 | bond | bondRefs | A reference to a list of bonds. | Used by electrons, bondSets, etc. |
| 150 | bond | order | The order of the bond. | There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations. |
| 151 | bondArray | title | A title on an element. | No controlled value. |
| 152 | bondArray | id | An attribute providing a unique ID for an element. | |
| 153 | bondArray | convention | A reference to a convention. | 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. |
| 154 | bondArray | dictRef | 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 |
| 155 | bondArray | bondIDArray | The IDs for an array of bonds | |
| 156 | bondArray | atomRef1Array | The first atoms in each bond | Currently only used in bondArray in CML2 array mode |
| 157 | bondArray | atomRef2Array | The second atoms in each bond. | |
| 158 | bondArray | orderArray | The order of the bond. | There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations. |
| 159 | bondSet | title | A title on an element. | No controlled value. |
| 160 | bondSet | id | An attribute providing a unique ID for an element. | |
| 161 | bondSet | convention | A reference to a convention. | 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. |
| 162 | bondSet | dictRef | 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 |
| 163 | bondSet | size | The size of an array or matrix | |
| 164 | bondStereo | atomRefs4 | A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 165 | bondStereo | atomRefArray | An array of references to atoms. | Typical use would be to atoms defining a plane. |
| 166 | bondStereo | title | A title on an element. | No controlled value. |
| 167 | bondStereo | id | An attribute providing a unique ID for an element. | |
| 168 | bondStereo | convention | A reference to a convention. | 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. |
| 169 | bondStereo | dictRef | 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 |
| 170 | bondStereo | conventionValue | The value of an element when the _convention_ attribute is used | When convention is used this attribute must be present and element content must be empty. |
| 171 | bondType | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 172 | bondType | ref | A reference to an element of given type. | ref 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. |
| 173 | bondType | title | A title on an element. | No controlled value. |
| 174 | bondType | id | An attribute providing a unique ID for an element. | |
| 175 | bondType | convention | A reference to a convention. | 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. |
| 176 | bondType | dictRef | 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 |
| 177 | bondTypeList | dictRef | 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 |
| 178 | bondTypeList | convention | A reference to a convention. | 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. |
| 179 | bondTypeList | title | A title on an element. | No controlled value. |
| 180 | bondTypeList | id | An attribute providing a unique ID for an element. | |
| 181 | bondTypeList | ref | A reference to an element of given type. | ref 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. |
| 182 | cml | title | A title on an element. | No controlled value. |
| 183 | cml | id | An attribute providing a unique ID for an element. | |
| 184 | cml | convention | A reference to a convention. | 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. |
| 185 | cml | dictRef | 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 |
| 186 | conditionList | dictRef | 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 |
| 187 | conditionList | convention | A reference to a convention. | 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. |
| 188 | conditionList | title | A title on an element. | No controlled value. |
| 189 | conditionList | id | An attribute providing a unique ID for an element. | |
| 190 | conditionList | ref | A reference to an element of given type. | ref 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. |
| 191 | conditionList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 192 | crystal | z | The number of molecules per cell. | Molecules are defined as the _molecule_ which directly contains the _crystal_ element. |
| 193 | crystal | title | A title on an element. | No controlled value. |
| 194 | crystal | id | An attribute providing a unique ID for an element. | |
| 195 | crystal | convention | A reference to a convention. | 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. |
| 196 | crystal | dictRef | 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 |
| 197 | description | id | An attribute providing a unique ID for an element. | |
| 198 | description | objectClass | The class of an object | The type of this information. This is not controlled, but examples might include: label summary note usage qualifier It might be used to control display or XSL filtering. |
| 199 | dictionary | title | A title on an element. | No controlled value. |
| 200 | dictionary | id | An attribute providing a unique ID for an element. | |
| 201 | dictionary | convention | A reference to a convention. | 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. |
| 202 | dictionary | dictRef | 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 |
| 203 | dictionary | href | address of a resource | 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. |
| 204 | dimension | id | An attribute providing a unique ID for an element. | |
| 205 | dimension | dimensionBasis | The basis of the dimension. | Normally taken from the seven SI types but possibly expandable. |
| 206 | dimension | power | The power to which a dimension should be raised. | Normally an integer. Must be included, even if unity. |
| 207 | dimension | preserve | Is the dimension preserved during algebra | |
| 208 | documentation | id | An attribute providing a unique ID for an element. | |
| 209 | eigen | units | Scientific units on an element. | 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. |
| 210 | eigen | title | A title on an element. | No controlled value. |
| 211 | eigen | id | An attribute providing a unique ID for an element. | |
| 212 | eigen | convention | A reference to a convention. | 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. |
| 213 | eigen | dictRef | 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 |
| 214 | eigen | type | Type of the object | A qualifier which may affect the semantics of the object |
| 215 | electron | title | A title on an element. | No controlled value. |
| 216 | electron | id | An attribute providing a unique ID for an element. | |
| 217 | electron | convention | A reference to a convention. | 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. |
| 218 | electron | dictRef | 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 |
| 219 | electron | atomRef | A reference to an atom. | Used by bond, electron, etc. |
| 220 | electron | atomRefs | A reference to a list of atoms. | Used by bonds, electrons, atomSets, etc. |
| 221 | electron | bondRef | A reference to a bond | used by electron, etc. |
| 222 | electron | bondRefs | A reference to a list of bonds. | Used by electrons, bondSets, etc. |
| 223 | electron | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 224 | electron | ref | A reference to an element of given type. | ref 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. |
| 225 | entry | title | A title on an element. | No controlled value. |
| 226 | entry | id | An attribute providing a unique ID for an element. | |
| 227 | entry | convention | A reference to a convention. | 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. |
| 228 | entry | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 229 | entry | rows | Number of rows. | |
| 230 | entry | columns | Number of columns. | |
| 231 | entry | unitType | A reference to the type of a unit. | Used in defining the unit and doing symbolic algebra on the dimensionality |
| 232 | entry | minExclusive | minimum exclusive value | by analogy with xsd:schema |
| 233 | entry | minInclusive | minimum inclusive value | by analogy with xsd:schema |
| 234 | entry | maxExclusive | maximum excelusive value | by analogy with xsd:schema |
| 235 | entry | maxInclusive | minimum inclusive value | by analogy with xsd:schema |
| 236 | entry | totalDigits | total digits in a scalar | based on xsd:schema |
| 237 | entry | fractionDigits | Number of digits after the point | |
| 238 | entry | length | Length of a scalar | Probably will be replaced with xsd:schema tools |
| 239 | entry | minLength | minimum length of a scalar | by analogy with xsd:schema |
| 240 | entry | maxLength | maximum length of a scalar | by analogy with xsd:schema |
| 241 | entry | units | Scientific units on an element. | 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. |
| 242 | entry | whiteSpace | whitespace | attached to entry. This may be obsolete |
| 243 | entry | pattern | Pattern constraint | Based on xsd:schema |
| 244 | entry | term | A term in a dictionary | The term should be a noun or nounal phrase, with a separate definition and further description |
| 245 | enumeration | value | Value of a scalar object | The value must be consistent with the dataType of the object |
| 246 | enumeration | dictRef | 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 |
| 247 | enumeration | default | default value in an enumeration | 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. |
| 248 | expression | title | A title on an element. | No controlled value. |
| 249 | expression | id | An attribute providing a unique ID for an element. | |
| 250 | expression | convention | A reference to a convention. | 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. |
| 251 | expression | dictRef | 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 |
| 252 | expression | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 253 | formula | title | A title on an element. | No controlled value. |
| 254 | formula | id | An attribute providing a unique ID for an element. | |
| 255 | formula | convention | A reference to a convention. | 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. |
| 256 | formula | dictRef | 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 |
| 257 | formula | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 258 | formula | formalCharge | The formalCharge on the object | 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. |
| 259 | formula | concise | A concise formula | |
| 260 | gradient | title | A title on an element. | No controlled value. |
| 261 | gradient | id | An attribute providing a unique ID for an element. | |
| 262 | gradient | convention | A reference to a convention. | 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. |
| 263 | gradient | dictRef | 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 |
| 264 | identifier | version | The version of the identifier. | |
| 265 | identifier | title | A title on an element. | No controlled value. |
| 266 | identifier | id | An attribute providing a unique ID for an element. | |
| 267 | identifier | convention | A reference to a convention. | 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. |
| 268 | identifier | dictRef | 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 |
| 269 | identifier | tautomeric | Indicates whether the structure is a tautomer | |
| 270 | isotope | title | A title on an element. | No controlled value. |
| 271 | isotope | id | An attribute providing a unique ID for an element. | |
| 272 | isotope | convention | A reference to a convention. | 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. |
| 273 | isotope | dictRef | 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 |
| 274 | isotope | isotopeNumber | The integer number for an isotope. | The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef). |
| 275 | isotope | spin | The spin of a system | Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope. |
| 276 | isotope | elementType | The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 277 | isotope | ref | A reference to an element of given type. | ref 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. |
| 278 | isotopeList | dictRef | 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 |
| 279 | isotopeList | convention | A reference to a convention. | 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. |
| 280 | isotopeList | title | A title on an element. | No controlled value. |
| 281 | isotopeList | id | An attribute providing a unique ID for an element. | |
| 282 | isotopeList | ref | A reference to an element of given type. | ref 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. |
| 283 | label | id | An attribute providing a unique ID for an element. | |
| 284 | label | dictRef | 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 |
| 285 | label | value | Value of a scalar object | The value must be consistent with the dataType of the object |
| 286 | label | objectClass | The class of an object | The type of this information. This is not controlled, but examples might include: label summary note usage qualifier It might be used to control display or XSL filtering. |
| 287 | lattice | title | A title on an element. | No controlled value. |
| 288 | lattice | id | An attribute providing a unique ID for an element. | |
| 289 | lattice | convention | A reference to a convention. | 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. |
| 290 | lattice | dictRef | 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 |
| 291 | lattice | latticeType | The primitivity of a lattice. | |
| 292 | lattice | spaceType | The spaceType of the lattice. | |
| 293 | latticeVector | convention | A reference to a convention. | 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. |
| 294 | latticeVector | dictRef | 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 |
| 295 | latticeVector | id | An attribute providing a unique ID for an element. | |
| 296 | latticeVector | title | A title on an element. | No controlled value. |
| 297 | latticeVector | units | Scientific units on an element. | 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. |
| 298 | latticeVector | periodic | Is the axis periodic | 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 |
| 299 | length | title | A title on an element. | No controlled value. |
| 300 | length | id | An attribute providing a unique ID for an element. | |
| 301 | length | convention | A reference to a convention. | 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. |
| 302 | length | dictRef | 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 |
| 303 | length | atomRefs2 | References to two different atoms | 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) |
| 304 | length | units | Scientific units on an element. | 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. |
| 305 | length | errorValue | Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 306 | length | errorBasis | Basis of the error estimate | |
| 307 | length | min | The minimum value allowed for an element or attribute. | |
| 308 | length | max | Maximum value allowed for an element or attribute. | |
| 309 | length | ref | A reference to an element of given type. | ref 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. |
| 310 | line3 | convention | A reference to a convention. | 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. |
| 311 | line3 | dictRef | 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 |
| 312 | line3 | id | An attribute providing a unique ID for an element. | |
| 313 | line3 | title | A title on an element. | No controlled value. |
| 314 | line3 | units | Scientific units on an element. | 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. |
| 315 | link | title | A title on an element. | No controlled value. |
| 316 | link | id | An attribute providing a unique ID for an element. | |
| 317 | link | convention | A reference to a convention. | 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. |
| 318 | link | dictRef | 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 |
| 319 | link | from | The base of a link. | |
| 320 | link | to | The target of a link. | |
| 321 | link | ref | A reference to an element of given type. | ref 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. |
| 322 | link | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 323 | link | href | address of a resource | 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. |
| 324 | link | linkType | The type of the link. | |
| 325 | list | title | A title on an element. | No controlled value. |
| 326 | list | id | An attribute providing a unique ID for an element. | |
| 327 | list | convention | A reference to a convention. | 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. |
| 328 | list | dictRef | 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 |
| 329 | list | type | Type of the object | A qualifier which may affect the semantics of the object |
| 330 | map | title | A title on an element. | No controlled value. |
| 331 | map | id | An attribute providing a unique ID for an element. | |
| 332 | map | convention | A reference to a convention. | 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. |
| 333 | map | dictRef | 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 |
| 334 | map | from | The base of a link. | |
| 335 | map | to | The target of a link. | |
| 336 | matrix | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 337 | matrix | delimiter | A delimiter character for arrays and matrices. | By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely: 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> 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. |
| 338 | matrix | rows | Number of rows. | |
| 339 | matrix | columns | Number of columns. | |
| 340 | matrix | units | Scientific units on an element. | 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. |
| 341 | matrix | title | A title on an element. | No controlled value. |
| 342 | matrix | id | An attribute providing a unique ID for an element. | |
| 343 | matrix | convention | A reference to a convention. | 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. |
| 344 | matrix | dictRef | 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 |
| 345 | matrix | matrixType | Type of matrix. | Mainly square, but extensible through the _xsd:union_ mechanism |
| 346 | matrix | errorValueArray | Array of error values | Reports the author's estimate of the error in an array of values. Only meaningful for dataTypes mapping to real numbers |
| 347 | matrix | errorBasis | Basis of the error estimate | |
| 348 | matrix | minValueArray | Minimum values for numeric _matrix_ or _array_ | A whitespace-separated lists of the same length as the array in the parent element |
| 349 | matrix | maxValueArray | Maximum values for numeric _matrix_ or _array_ | A whitespace-separated list of the same length as the array in the parent element |
| 350 | mechanism | title | A title on an element. | No controlled value. |
| 351 | mechanism | id | An attribute providing a unique ID for an element. | |
| 352 | mechanism | convention | A reference to a convention. | 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. |
| 353 | mechanism | dictRef | 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 |
| 354 | mechanismComponent | title | A title on an element. | No controlled value. |
| 355 | mechanismComponent | id | An attribute providing a unique ID for an element. | |
| 356 | mechanismComponent | convention | A reference to a convention. | 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. |
| 357 | mechanismComponent | dictRef | 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 |
| 358 | metadata | metadataType | The metadata type. | |
| 359 | metadata | title | A title on an element. | No controlled value. |
| 360 | metadata | id | An attribute providing a unique ID for an element. | |
| 361 | metadata | convention | A reference to a convention. | 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. |
| 362 | metadata | dictRef | 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 |
| 363 | metadata | content | content of metadata | |
| 364 | metadataList | id | An attribute providing a unique ID for an element. | |
| 365 | metadataList | title | A title on an element. | No controlled value. |
| 366 | metadataList | convention | A reference to a convention. | 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. |
| 367 | metadataList | dictRef | 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 |
| 368 | module | serial | Serial number or other id | |
| 369 | module | title | A title on an element. | No controlled value. |
| 370 | module | id | An attribute providing a unique ID for an element. | |
| 371 | module | convention | A reference to a convention. | 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. |
| 372 | module | dictRef | 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 |
| 373 | module | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 374 | molecule | dictRef | 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 |
| 375 | molecule | convention | A reference to a convention. | 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. |
| 376 | molecule | title | A title on an element. | No controlled value. |
| 377 | molecule | id | An attribute providing a unique ID for an element. | |
| 378 | molecule | ref | A reference to an element of given type. | ref 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. |
| 379 | molecule | formula | Simple chemical formula | |
| 380 | molecule | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 381 | molecule | chirality | The chirality of a system or molecule | This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default. |
| 382 | molecule | formalCharge | The formalCharge on the object | 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. |
| 383 | molecule | spinMultiplicity | Spin multiplicity | 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) |
| 384 | molecule | symmetryOriented | Is the molecule oriented to the symmetry. | 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 |
| 385 | molecule | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 386 | name | id | An attribute providing a unique ID for an element. | |
| 387 | name | convention | A reference to a convention. | 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. |
| 388 | name | dictRef | 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 |
| 389 | object | title | A title on an element. | No controlled value. |
| 390 | object | id | An attribute providing a unique ID for an element. | |
| 391 | object | convention | A reference to a convention. | 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. |
| 392 | object | dictRef | 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 |
| 393 | object | type | Type of the object | A qualifier which may affect the semantics of the object |
| 394 | object | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 395 | observation | title | A title on an element. | No controlled value. |
| 396 | observation | id | An attribute providing a unique ID for an element. | |
| 397 | observation | convention | A reference to a convention. | 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. |
| 398 | observation | dictRef | 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 |
| 399 | observation | type | Type of the object | A qualifier which may affect the semantics of the object |
| 400 | observation | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 401 | operator | title | A title on an element. | No controlled value. |
| 402 | operator | id | An attribute providing a unique ID for an element. | |
| 403 | operator | convention | A reference to a convention. | 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. |
| 404 | operator | dictRef | 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 |
| 405 | operator | type | Type of the object | A qualifier which may affect the semantics of the object |
| 406 | parameter | ref | A reference to an element of given type. | ref 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. |
| 407 | parameter | title | A title on an element. | No controlled value. |
| 408 | parameter | id | An attribute providing a unique ID for an element. | |
| 409 | parameter | convention | A reference to a convention. | 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. |
| 410 | parameter | dictRef | 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 |
| 411 | parameter | value | Value of a scalar object | The value must be consistent with the dataType of the object |
| 412 | parameter | constraint | Constraint on a parameter | Semantics not yet finalised. We anticipate "fixed", "none" and symbolic relationships to other parameters. |
| 413 | parameter | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 414 | parameter | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 415 | parameterList | dictRef | 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 |
| 416 | parameterList | convention | A reference to a convention. | 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. |
| 417 | parameterList | title | A title on an element. | No controlled value. |
| 418 | parameterList | id | An attribute providing a unique ID for an element. | |
| 419 | parameterList | ref | A reference to an element of given type. | ref 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. |
| 420 | parameterList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 421 | particle | title | A title on an element. | No controlled value. |
| 422 | particle | id | An attribute providing a unique ID for an element. | |
| 423 | particle | convention | A reference to a convention. | 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. |
| 424 | particle | dictRef | 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 |
| 425 | particle | type | Type of the object | A qualifier which may affect the semantics of the object |
| 426 | particle | xyz3 | group of attributes for arrays of x3 y3 z3 | |
| 427 | peak | dictRef | 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 |
| 428 | peak | convention | A reference to a convention. | 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. |
| 429 | peak | title | A title on an element. | No controlled value. |
| 430 | peak | id | An attribute providing a unique ID for an element. | |
| 431 | peak | ref | A reference to an element of given type. | ref 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. |
| 432 | peak | peakHeight | Height of a peak | For 1-dimensional data (e.g. y vs x) hould use the same units as the appropriate axis (e.g. y). |
| 433 | peak | peakMultiplicity | Multiplicity of a peak | Uses a semi-controlled vocabulary |
| 434 | peak | peakShape | Shape of a peak | Semi-controlled vocabulary such as broad or sharp |
| 435 | peak | integral | Area under a peak | Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be used |
| 436 | peak | peakUnits | Units for a peak or peak integral | For 2-dimensional spectra the units represent th 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. |
| 437 | peak | xMin | Minimum yValue | 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. |
| 438 | peak | xMax | Maximum yValue | 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. |
| 439 | peak | xValue | Value along an x axis | 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. |
| 440 | peak | xWidth | An unsigned interval along an x axis | 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. |
| 441 | peak | xUnits | Units for x axis | 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. |
| 442 | peak | yMin | Minimum yValue | 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. |
| 443 | peak | yMax | Maximum yValue | 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. |
| 444 | peak | yValue | Value along a y axis | 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. |
| 445 | peak | yWidth | An unsigned interval along a y axis | 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. |
| 446 | peak | yUnits | Units for y axis | 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. |
| 447 | peakGroup | dictRef | 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 |
| 448 | peakGroup | convention | A reference to a convention. | 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. |
| 449 | peakGroup | title | A title on an element. | No controlled value. |
| 450 | peakGroup | id | An attribute providing a unique ID for an element. | |
| 451 | peakGroup | ref | A reference to an element of given type. | ref 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. |
| 452 | peakGroup | peakHeight | Height of a peak | For 1-dimensional data (e.g. y vs x) hould use the same units as the appropriate axis (e.g. y). |
| 453 | peakGroup | peakMultiplicity | Multiplicity of a peak | Uses a semi-controlled vocabulary |
| 454 | peakGroup | peakShape | Shape of a peak | Semi-controlled vocabulary such as broad or sharp |
| 455 | peakGroup | integral | Area under a peak | Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be used |
| 456 | peakGroup | peakUnits | Units for a peak or peak integral | For 2-dimensional spectra the units represent th 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. |
| 457 | peakGroup | xMin | Minimum yValue | 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. |
| 458 | peakGroup | xMax | Maximum yValue | 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. |
| 459 | peakGroup | xValue | Value along an x axis | 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. |
| 460 | peakGroup | xWidth | An unsigned interval along an x axis | 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. |
| 461 | peakGroup | xUnits | Units for x axis | 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. |
| 462 | peakGroup | yMin | Minimum yValue | 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. |
| 463 | peakGroup | yMax | Maximum yValue | 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. |
| 464 | peakGroup | yValue | Value along a y axis | 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. |
| 465 | peakGroup | yWidth | An unsigned interval along a y axis | 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. |
| 466 | peakGroup | yUnits | Units for y axis | 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. |
| 467 | peakList | dictRef | 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 |
| 468 | peakList | convention | A reference to a convention. | 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. |
| 469 | peakList | title | A title on an element. | No controlled value. |
| 470 | peakList | id | An attribute providing a unique ID for an element. | |
| 471 | peakList | ref | A reference to an element of given type. | ref 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. |
| 472 | plane3 | convention | A reference to a convention. | 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. |
| 473 | plane3 | dictRef | 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 |
| 474 | plane3 | id | An attribute providing a unique ID for an element. | |
| 475 | plane3 | title | A title on an element. | No controlled value. |
| 476 | plane3 | units | Scientific units on an element. | 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. |
| 477 | point3 | convention | A reference to a convention. | 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. |
| 478 | point3 | dictRef | 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 |
| 479 | point3 | id | An attribute providing a unique ID for an element. | |
| 480 | point3 | title | A title on an element. | No controlled value. |
| 481 | point3 | units | Scientific units on an element. | 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. |
| 482 | potential | title | A title on an element. | No controlled value. |
| 483 | potential | id | An attribute providing a unique ID for an element. | |
| 484 | potential | convention | A reference to a convention. | 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. |
| 485 | potential | dictRef | 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 |
| 486 | potentialForm | title | A title on an element. | No controlled value. |
| 487 | potentialForm | id | An attribute providing a unique ID for an element. | |
| 488 | potentialForm | convention | A reference to a convention. | 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. |
| 489 | potentialForm | dictRef | 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 |
| 490 | potentialForm | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 491 | potentialList | title | A title on an element. | No controlled value. |
| 492 | potentialList | id | An attribute providing a unique ID for an element. | |
| 493 | potentialList | convention | A reference to a convention. | 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. |
| 494 | potentialList | dictRef | 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 |
| 495 | product | dictRef | 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 |
| 496 | product | convention | A reference to a convention. | 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. |
| 497 | product | title | A title on an element. | No controlled value. |
| 498 | product | id | An attribute providing a unique ID for an element. | |
| 499 | product | ref | A reference to an element of given type. | ref 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. |
| 500 | product | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 501 | product | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 502 | product | state | The physical state of the substance. | No fixed semantics or default. |
| 503 | productList | dictRef | 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 |
| 504 | productList | convention | A reference to a convention. | 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. |
| 505 | productList | title | A title on an element. | No controlled value. |
| 506 | productList | id | An attribute providing a unique ID for an element. | |
| 507 | productList | ref | A reference to an element of given type. | ref 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. |
| 508 | productList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 509 | productList | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 510 | property | dictRef | 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 |
| 511 | property | convention | A reference to a convention. | 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. |
| 512 | property | title | A title on an element. | No controlled value. |
| 513 | property | id | An attribute providing a unique ID for an element. | |
| 514 | property | ref | A reference to an element of given type. | ref 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. |
| 515 | property | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 516 | property | state | The physical state of the substance. | No fixed semantics or default. |
| 517 | propertyList | dictRef | 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 |
| 518 | propertyList | convention | A reference to a convention. | 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. |
| 519 | propertyList | title | A title on an element. | No controlled value. |
| 520 | propertyList | id | An attribute providing a unique ID for an element. | |
| 521 | propertyList | ref | A reference to an element of given type. | ref 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. |
| 522 | propertyList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 523 | reactant | dictRef | 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 |
| 524 | reactant | convention | A reference to a convention. | 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. |
| 525 | reactant | title | A title on an element. | No controlled value. |
| 526 | reactant | id | An attribute providing a unique ID for an element. | |
| 527 | reactant | ref | A reference to an element of given type. | ref 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. |
| 528 | reactant | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 529 | reactant | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 530 | reactant | state | The physical state of the substance. | No fixed semantics or default. |
| 531 | reactantList | dictRef | 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 |
| 532 | reactantList | convention | A reference to a convention. | 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. |
| 533 | reactantList | title | A title on an element. | No controlled value. |
| 534 | reactantList | id | An attribute providing a unique ID for an element. | |
| 535 | reactantList | ref | A reference to an element of given type. | ref 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. |
| 536 | reactantList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 537 | reactantList | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 538 | reaction | dictRef | 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 |
| 539 | reaction | convention | A reference to a convention. | 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. |
| 540 | reaction | title | A title on an element. | No controlled value. |
| 541 | reaction | id | An attribute providing a unique ID for an element. | |
| 542 | reaction | ref | A reference to an element of given type. | ref 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. |
| 543 | reaction | reactionRole | Role of the reaction | |
| 544 | reaction | reactionType | Type of the reaction | |
| 545 | reaction | state | The physical state of the substance. | No fixed semantics or default. |
| 546 | reactionList | dictRef | 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 |
| 547 | reactionList | convention | A reference to a convention. | 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. |
| 548 | reactionList | title | A title on an element. | No controlled value. |
| 549 | reactionList | id | An attribute providing a unique ID for an element. | |
| 550 | reactionList | ref | A reference to an element of given type. | ref 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. |
| 551 | reactionScheme | dictRef | 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 |
| 552 | reactionScheme | convention | A reference to a convention. | 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. |
| 553 | reactionScheme | title | A title on an element. | No controlled value. |
| 554 | reactionScheme | id | An attribute providing a unique ID for an element. | |
| 555 | reactionScheme | ref | A reference to an element of given type. | ref 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. |
| 556 | reactionScheme | reactionRole | Role of the reaction | |
| 557 | reactionScheme | reactionType | Type of the reaction | |
| 558 | reactionScheme | state | The physical state of the substance. | No fixed semantics or default. |
| 559 | reactionStepList | dictRef | 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 |
| 560 | reactionStepList | convention | A reference to a convention. | 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. |
| 561 | reactionStepList | title | A title on an element. | No controlled value. |
| 562 | reactionStepList | id | An attribute providing a unique ID for an element. | |
| 563 | reactionStepList | ref | A reference to an element of given type. | ref 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. |
| 564 | reactionStepList | scheme | The sequence of steps in a reactionList | 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. |
| 565 | reactiveCentre | title | A title on an element. | No controlled value. |
| 566 | reactiveCentre | id | An attribute providing a unique ID for an element. | |
| 567 | reactiveCentre | convention | A reference to a convention. | 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. |
| 568 | reactiveCentre | dictRef | 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 |
| 569 | region | sphere3 | A sphere | Currently describes a region. Any point falling within the sphere or on its surface is within the region |
| 570 | region | box3 | A parallelipiped box | 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 region |
| 571 | region | atomSetRef | An atomSet describing the region | Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments. |
| 572 | region | regionRefs | A list of regions creating a union | 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. |
| 573 | region | title | A title on an element. | No controlled value. |
| 574 | region | id | An attribute providing a unique ID for an element. | |
| 575 | region | convention | A reference to a convention. | 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. |
| 576 | region | dictRef | 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 |
| 577 | relatedEntry | relatedEntryType | Type of relatedEntry | Type represents a the type of relationship in a relatedEntry element. |
| 578 | relatedEntry | href | address of a resource | 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. |
| 579 | sample | dictRef | 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 |
| 580 | sample | convention | A reference to a convention. | 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. |
| 581 | sample | title | A title on an element. | No controlled value. |
| 582 | sample | id | An attribute providing a unique ID for an element. | |
| 583 | sample | ref | A reference to an element of given type. | ref 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. |
| 584 | sample | state | The physical state of the substance. | No fixed semantics or default. |
| 585 | scalar | title | A title on an element. | No controlled value. |
| 586 | scalar | id | An attribute providing a unique ID for an element. | |
| 587 | scalar | convention | A reference to a convention. | 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. |
| 588 | scalar | dictRef | 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 |
| 589 | scalar | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 590 | scalar | errorValue | Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 591 | scalar | errorBasis | Basis of the error estimate | |
| 592 | scalar | min | The minimum value allowed for an element or attribute. | |
| 593 | scalar | max | Maximum value allowed for an element or attribute. | |
| 594 | scalar | units | Scientific units on an element. | 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. |
| 595 | spectator | title | A title on an element. | No controlled value. |
| 596 | spectator | id | An attribute providing a unique ID for an element. | |
| 597 | spectator | convention | A reference to a convention. | 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. |
| 598 | spectator | dictRef | 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 |
| 599 | spectator | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 600 | spectatorList | title | A title on an element. | No controlled value. |
| 601 | spectatorList | id | An attribute providing a unique ID for an element. | |
| 602 | spectatorList | convention | A reference to a convention. | 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. |
| 603 | spectatorList | dictRef | 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 |
| 604 | spectrum | dictRef | 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 |
| 605 | spectrum | convention | A reference to a convention. | 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. |
| 606 | spectrum | title | A title on an element. | No controlled value. |
| 607 | spectrum | id | An attribute providing a unique ID for an element. | |
| 608 | spectrum | ref | A reference to an element of given type. | ref 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. |
| 609 | spectrum | moleculeRef | A reference to a molecule. | Used by spectrum, etc. |
| 610 | spectrum | spectrumType | The type of the spectrum. | |
| 611 | spectrum | format | Format of a spectrum | The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted. |
| 612 | spectrum | measurement | Type of spectral measurement | 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. |
| 613 | spectrum | ft | Domain of an FT spectrum | Indicates whether a spectrum is raw FID or has been transformed |
| 614 | spectrum | state | The physical state of the substance. | No fixed semantics or default. |
| 615 | spectrumData | dictRef | 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 |
| 616 | spectrumData | convention | A reference to a convention. | 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. |
| 617 | spectrumData | title | A title on an element. | No controlled value. |
| 618 | spectrumData | id | An attribute providing a unique ID for an element. | |
| 619 | spectrumData | ref | A reference to an element of given type. | ref 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. |
| 620 | spectrumList | dictRef | 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 |
| 621 | spectrumList | convention | A reference to a convention. | 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. |
| 622 | spectrumList | title | A title on an element. | No controlled value. |
| 623 | spectrumList | id | An attribute providing a unique ID for an element. | |
| 624 | spectrumList | ref | A reference to an element of given type. | ref 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. |
| 625 | spectrumList | moleculeRef | A reference to a molecule. | Used by spectrum, etc. |
| 626 | sphere3 | convention | A reference to a convention. | 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. |
| 627 | sphere3 | dictRef | 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 |
| 628 | sphere3 | id | An attribute providing a unique ID for an element. | |
| 629 | sphere3 | title | A title on an element. | No controlled value. |
| 630 | sphere3 | units | Scientific units on an element. | 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. |
| 631 | stmml | title | A title on an element. | No controlled value. |
| 632 | stmml | id | An attribute providing a unique ID for an element. | |
| 633 | stmml | convention | A reference to a convention. | 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. |
| 634 | stmml | dictRef | 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 |
| 635 | substance | dictRef | 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 |
| 636 | substance | convention | A reference to a convention. | 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. |
| 637 | substance | title | A title on an element. | No controlled value. |
| 638 | substance | id | An attribute providing a unique ID for an element. | |
| 639 | substance | type | Type of the object | A qualifier which may affect the semantics of the object |
| 640 | substance | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 641 | substance | ref | A reference to an element of given type. | ref 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. |
| 642 | substance | count | The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 643 | substance | state | The physical state of the substance. | No fixed semantics or default. |
| 644 | substanceList | dictRef | 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 |
| 645 | substanceList | convention | A reference to a convention. | 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. |
| 646 | substanceList | title | A title on an element. | No controlled value. |
| 647 | substanceList | id | An attribute providing a unique ID for an element. | |
| 648 | substanceList | substanceListType | Type of the substanceList: | Extension is allowed through the "other" value. |
| 649 | substanceList | role | Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 650 | substanceList | ref | A reference to an element of given type. | ref 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. |
| 651 | symmetry | dictRef | 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 |
| 652 | symmetry | convention | A reference to a convention. | 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. |
| 653 | symmetry | title | A title on an element. | No controlled value. |
| 654 | symmetry | id | An attribute providing a unique ID for an element. | |
| 655 | symmetry | pointGroup | A point group. | No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future. |
| 656 | symmetry | spaceGroup | A space group. | No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future. |
| 657 | symmetry | irreducibleRepresentation | A symmetry species. | No fixed semantics, though we may provide a controlled-extensible list in the future. |
| 658 | symmetry | number | The rotational symmetry number | Used for calculation of entropy, etc. |
| 659 | system | dimensionality | Dimensionality of a coordinate system. | |
| 660 | system | periodicity | Periodicity of the system. | |
| 661 | system | title | A title on an element. | No controlled value. |
| 662 | system | id | An attribute providing a unique ID for an element. | |
| 663 | system | convention | A reference to a convention. | 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. |
| 664 | system | dictRef | 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 |
| 665 | table | rows | Number of rows. | |
| 666 | table | columns | Number of columns. | |
| 667 | table | units | Scientific units on an element. | 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. |
| 668 | table | dataType | The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 669 | table | title | A title on an element. | No controlled value. |
| 670 | table | id | An attribute providing a unique ID for an element. | |
| 671 | table | convention | A reference to a convention. | 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. |
| 672 | table | dictRef | 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 |
| 673 | torsion | title | A title on an element. | No controlled value. |
| 674 | torsion | id | An attribute providing a unique ID for an element. | |
| 675 | torsion | convention | A reference to a convention. | 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. |
| 676 | torsion | dictRef | 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 |
| 677 | torsion | atomRefs4 | A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 678 | torsion | units | Scientific units on an element. | 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. |
| 679 | torsion | errorValue | Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 680 | torsion | errorBasis | Basis of the error estimate | |
| 681 | torsion | min | The minimum value allowed for an element or attribute. | |
| 682 | torsion | max | Maximum value allowed for an element or attribute. | |
| 683 | torsion | ref | A reference to an element of given type. | ref 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. |
| 684 | transitionState | title | A title on an element. | No controlled value. |
| 685 | transitionState | id | An attribute providing a unique ID for an element. | |
| 686 | transitionState | convention | A reference to a convention. | 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. |
| 687 | transitionState | dictRef | 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 |
| 688 | unit | id | An attribute providing a unique ID for an element. | |
| 689 | unit | abbreviation | Abbreviation | Abbreviation for units, terms, etc. |
| 690 | unit | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 691 | unit | parentSI | A dictRef like reference to the id of the parent SI unit. | 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. |
| 692 | unit | unitType | A reference to the type of a unit. | Used in defining the unit and doing symbolic algebra on the dimensionality |
| 693 | unit | multiplierToSI | Multiplier to generate SI equivalent. | 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 units |
| 694 | unit | constantToSI | Additive constant to generate SI equivalent | 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. |
| 695 | unitList | title | A title on an element. | No controlled value. |
| 696 | unitList | id | An attribute providing a unique ID for an element. | |
| 697 | unitList | convention | A reference to a convention. | 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. |
| 698 | unitList | dictRef | 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 |
| 699 | unitList | href | address of a resource | 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. |
| 700 | unitType | id | An attribute providing a unique ID for an element. | |
| 701 | unitType | name | Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 702 | vector3 | convention | A reference to a convention. | 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. |
| 703 | vector3 | dictRef | 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 |
| 704 | vector3 | id | An attribute providing a unique ID for an element. | |
| 705 | vector3 | title | A title on an element. | No controlled value. |
| 706 | vector3 | units | Scientific units on an element. | 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. |
| 707 | xaxis | dictRef | 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 |
| 708 | xaxis | convention | A reference to a convention. | 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. |
| 709 | xaxis | title | A title on an element. | No controlled value. |
| 710 | xaxis | id | An attribute providing a unique ID for an element. | |
| 711 | xaxis | ref | A reference to an element of given type. | ref 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. |
| 712 | xaxis | multiplierToData | The scale by which to multiply the raw data | The scale is applied *before* adding the constant. |
| 713 | xaxis | constantToData | The constant to add to the raw data | add *after* applying any multiplier. |
| 714 | yaxis | dictRef | 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 |
| 715 | yaxis | convention | A reference to a convention. | 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. |
| 716 | yaxis | title | A title on an element. | No controlled value. |
| 717 | yaxis | id | An attribute providing a unique ID for an element. | |
| 718 | yaxis | ref | A reference to an element of given type. | ref 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. |
| 719 | yaxis | multiplierToData | The scale by which to multiply the raw data | The scale is applied *before* adding the constant. |
| 720 | yaxis | constantToData | The constant to add to the raw data | add *after* applying any multiplier. |
| 721 | zMatrix | title | A title on an element. | No controlled value. |
| 722 | zMatrix | id | An attribute providing a unique ID for an element. | |
| 723 | zMatrix | convention | A reference to a convention. | 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. |
| 724 | zMatrix | dictRef | 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 |
| pos | elem | att | ? | summary | desc |
|---|---|---|---|---|---|
| 1 | abbreviation | unit |
|
Abbreviation | Abbreviation for units, terms, etc. |
| 2 | actionGroup | action |
|
The start time. | The start time in any allowable XSD representation of date, time or dateTime. This will normally be a clock time or date. |
| 3 | actionGroup | actionList |
|
The start time. | The start time in any allowable XSD representation of date, time or dateTime. This will normally be a clock time or date. |
| 4 | actionOrder | actionList |
|
Describes whether child elements are sequential or parallel. There is no default. | |
| 5 | alternativeType | alternative |
|
The type of an alternative | |
| 6 | angleUnits | angle |
|
Restricts units to radians or degrees. | |
| 7 | atomIDArray | atomArray |
|
An array of atomIDs | Normally an attribute of an array-based element |
| 8 | atomRef | atomicBasisFunction |
The atom owning this atomicBasisFunction. This reference is required to tie the reported eigenvector components to the list
of atoms.
|
A reference to an atom. | Used by bond, electron, etc. |
| 9 | atomRef | atomType |
|
A reference to an atom. | Used by bond, electron, etc. |
| 10 | atomRef | electron |
|
A reference to an atom. | Used by bond, electron, etc. |
| 11 | atomRef1Array | bondArray |
|
The first atoms in each bond | Currently only used in bondArray in CML2 array mode |
| 12 | atomRef2Array | bondArray |
|
The second atoms in each bond. | |
| 13 | atomRefArray | bondStereo |
|
An array of references to atoms. | Typical use would be to atoms defining a plane. |
| 14 | atomRefs | bond |
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"/>
|
A reference to a list of atoms. | Used by bonds, electrons, atomSets, etc. |
| 15 | atomRefs | electron |
|
A reference to a list of atoms. | Used by bonds, electrons, atomSets, etc. |
| 16 | atomRefs2 | bond |
|
References to two different atoms | 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) |
| 17 | atomRefs2 | length |
|
References to two different atoms | 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) |
| 18 | atomRefs3 | angle |
|
A list of three references to atoms. | Typically used for defining angles, but could also be used to define a three-centre bond. |
| 19 | atomRefs4 | atomParity |
|
A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 20 | atomRefs4 | bondStereo |
|
A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 21 | atomRefs4 | torsion |
|
A list of 4 references to atoms. | Typically used for defining torsions and atomParities, but could also be used to define a four-centre bond. |
| 22 | atomSetRef | region |
|
An atomSet describing the region | Any point falling within atomOffset of any atom in the set lies within the region. This means the region could consist of disjoint fragments. |
| 23 | bondIDArray | bondArray |
|
The IDs for an array of bonds | |
| 24 | bondRef | electron |
|
A reference to a bond | used by electron, etc. |
| 25 | bondRefs | bond |
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"/>
|
A reference to a list of bonds. | Used by electrons, bondSets, etc. |
| 26 | bondRefs | electron |
|
A reference to a list of bonds. | Used by electrons, bondSets, etc. |
| 27 | box3 | region |
|
A parallelipiped box | 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 region |
| 28 | chirality | molecule |
|
The chirality of a system or molecule | This is being actively investigated by a IUPAC committee (2002) so the convention is likely to change. No formal default. |
| 29 | columns | entry |
|
Number of columns. | |
| 30 | columns | matrix |
|
Number of columns. | |
| 31 | columns | table |
|
Number of columns. | |
| 32 | concise | formula |
|
A concise formula | |
| 33 | constantToData | xaxis |
|
The constant to add to the raw data | add *after* applying any multiplier. |
| 34 | constantToData | yaxis |
|
The constant to add to the raw data | add *after* applying any multiplier. |
| 35 | constantToSI | unit |
|
Additive constant to generate SI equivalent | 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. |
| 36 | constraint | parameter |
|
Constraint on a parameter | Semantics not yet finalised. We anticipate "fixed", "none" and symbolic relationships to other parameters. |
| 37 | content | metadata |
|
content of metadata | |
| 38 | convention | abundance |
|
A reference to a convention. | 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. |
| 39 | convention | action |
|
A reference to a convention. | 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. |
| 40 | convention | actionList |
|
A reference to a convention. | 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. |
| 41 | convention | alternative |
|
A reference to a convention. | 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. |
| 42 | convention | amount |
|
A reference to a convention. | 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. |
| 43 | convention | angle |
|
A reference to a convention. | 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. |
| 44 | convention | arg |
|
A reference to a convention. | 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. |
| 45 | convention | array |
|
A reference to a convention. | 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. |
| 46 | convention | atom |
|
A reference to a convention. | 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. |
| 47 | convention | atomArray |
|
A reference to a convention. | 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. |
| 48 | convention | atomicBasisFunction |
|
A reference to a convention. | 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. |
| 49 | convention | atomParity |
|
A reference to a convention. | 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. |
| 50 | convention | atomSet |
|
A reference to a convention. | 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. |
| 51 | convention | atomType |
|
A reference to a convention. | 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. |
| 52 | convention | atomTypeList |
|
A reference to a convention. | 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. |
| 53 | convention | band |
|
A reference to a convention. | 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. |
| 54 | convention | bandList |
|
A reference to a convention. | 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. |
| 55 | convention | basisSet |
|
A reference to a convention. | 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. |
| 56 | convention | bond |
|
A reference to a convention. | 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. |
| 57 | convention | bondArray |
|
A reference to a convention. | 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. |
| 58 | convention | bondSet |
|
A reference to a convention. | 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. |
| 59 | convention | bondStereo |
|
A reference to a convention. | 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. |
| 60 | convention | bondType |
|
A reference to a convention. | 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. |
| 61 | convention | bondTypeList |
|
A reference to a convention. | 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. |
| 62 | convention | cml |
|
A reference to a convention. | 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. |
| 63 | convention | conditionList |
|
A reference to a convention. | 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. |
| 64 | convention | crystal |
|
A reference to a convention. | 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. |
| 65 | convention | dictionary |
|
A reference to a convention. | 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. |
| 66 | convention | eigen |
|
A reference to a convention. | 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. |
| 67 | convention | electron |
|
A reference to a convention. | 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. |
| 68 | convention | entry |
|
A reference to a convention. | 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. |
| 69 | convention | expression |
|
A reference to a convention. | 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. |
| 70 | convention | formula |
|
A reference to a convention. | 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. |
| 71 | convention | gradient |
|
A reference to a convention. | 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. |
| 72 | convention | identifier |
|
A reference to a convention. | 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. |
| 73 | convention | isotope |
|
A reference to a convention. | 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. |
| 74 | convention | isotopeList |
|
A reference to a convention. | 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. |
| 75 | convention | lattice |
|
A reference to a convention. | 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. |
| 76 | convention | latticeVector |
|
A reference to a convention. | 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. |
| 77 | convention | length |
|
A reference to a convention. | 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. |
| 78 | convention | line3 |
|
A reference to a convention. | 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. |
| 79 | convention | link |
|
A reference to a convention. | 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. |
| 80 | convention | list |
|
A reference to a convention. | 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. |
| 81 | convention | map |
|
A reference to a convention. | 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. |
| 82 | convention | matrix |
|
A reference to a convention. | 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. |
| 83 | convention | mechanism |
|
A reference to a convention. | 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. |
| 84 | convention | mechanismComponent |
|
A reference to a convention. | 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. |
| 85 | convention | metadata |
|
A reference to a convention. | 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. |
| 86 | convention | metadataList |
|
A reference to a convention. | 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. |
| 87 | convention | module |
|
A reference to a convention. | 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. |
| 88 | convention | molecule |
|
A reference to a convention. | 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. |
| 89 | convention | name |
|
A reference to a convention. | 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. |
| 90 | convention | object |
|
A reference to a convention. | 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. |
| 91 | convention | observation |
|
A reference to a convention. | 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. |
| 92 | convention | operator |
|
A reference to a convention. | 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. |
| 93 | convention | parameter |
|
A reference to a convention. | 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. |
| 94 | convention | parameterList |
|
A reference to a convention. | 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. |
| 95 | convention | particle |
|
A reference to a convention. | 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. |
| 96 | convention | peak |
|
A reference to a convention. | 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. |
| 97 | convention | peakGroup |
|
A reference to a convention. | 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. |
| 98 | convention | peakList |
|
A reference to a convention. | 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. |
| 99 | convention | plane3 |
|
A reference to a convention. | 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. |
| 100 | convention | point3 |
|
A reference to a convention. | 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. |
| 101 | convention | potential |
|
A reference to a convention. | 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. |
| 102 | convention | potentialForm |
|
A reference to a convention. | 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. |
| 103 | convention | potentialList |
|
A reference to a convention. | 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. |
| 104 | convention | product |
|
A reference to a convention. | 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. |
| 105 | convention | productList |
|
A reference to a convention. | 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. |
| 106 | convention | property |
|
A reference to a convention. | 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. |
| 107 | convention | propertyList |
|
A reference to a convention. | 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. |
| 108 | convention | reactant |
|
A reference to a convention. | 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. |
| 109 | convention | reactantList |
|
A reference to a convention. | 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. |
| 110 | convention | reaction |
|
A reference to a convention. | 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. |
| 111 | convention | reactionList |
|
A reference to a convention. | 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. |
| 112 | convention | reactionScheme |
|
A reference to a convention. | 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. |
| 113 | convention | reactionStepList |
|
A reference to a convention. | 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. |
| 114 | convention | reactiveCentre |
|
A reference to a convention. | 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. |
| 115 | convention | region |
|
A reference to a convention. | 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. |
| 116 | convention | sample |
|
A reference to a convention. | 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. |
| 117 | convention | scalar |
|
A reference to a convention. | 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. |
| 118 | convention | spectator |
|
A reference to a convention. | 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. |
| 119 | convention | spectatorList |
|
A reference to a convention. | 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. |
| 120 | convention | spectrum |
|
A reference to a convention. | 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. |
| 121 | convention | spectrumData |
|
A reference to a convention. | 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. |
| 122 | convention | spectrumList |
|
A reference to a convention. | 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. |
| 123 | convention | sphere3 |
|
A reference to a convention. | 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. |
| 124 | convention | stmml |
|
A reference to a convention. | 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. |
| 125 | convention | substance |
|
A reference to a convention. | 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. |
| 126 | convention | substanceList |
|
A reference to a convention. | 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. |
| 127 | convention | symmetry |
|
A reference to a convention. | 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. |
| 128 | convention | system |
|
A reference to a convention. | 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. |
| 129 | convention | table |
|
A reference to a convention. | 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. |
| 130 | convention | torsion |
|
A reference to a convention. | 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. |
| 131 | convention | transitionState |
|
A reference to a convention. | 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. |
| 132 | convention | unitList |
|
A reference to a convention. | 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. |
| 133 | convention | vector3 |
|
A reference to a convention. | 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. |
| 134 | convention | xaxis |
|
A reference to a convention. | 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. |
| 135 | convention | yaxis |
|
A reference to a convention. | 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. |
| 136 | convention | zMatrix |
|
A reference to a convention. | 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. |
| 137 | conventionValue | bondStereo |
|
The value of an element when the _convention_ attribute is used | When convention is used this attribute must be present and element content must be empty. |
| 138 | count | atom |
Most useful in _formula_ but possibly useful in _atomArray_ where coordinates and connectivity is not defined. No formal default,
but assumed to be 1.
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 139 | count | electron |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 140 | count | formula |
Allows for fractional components.
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 141 | count | molecule |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 142 | count | object |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 143 | count | observation |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 144 | count | product |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 145 | count | productList |
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.
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 146 | count | reactant |
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). |
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 147 | count | reactantList |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 148 | count | substance |
|
The count of the object | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 149 | countArray | atomArray |
|
Array of object counts | No fixed semantics or default, normally integral. It is presumed that the element can be multiplied by the count value. |
| 150 | dataType | arg |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 151 | dataType | array |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 152 | dataType | entry |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 153 | dataType | expression |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 154 | dataType | matrix |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 155 | dataType | scalar |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 156 | dataType | table |
|
The data type of the object | Normally applied to scalar/array objects but may extend to more complex ones |
| 157 | default | enumeration |
|
default value in an enumeration | 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. |
| 158 | delimiter | array |
|
A delimiter character for arrays and matrices. | By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely: 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> 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. |
| 159 | delimiter | matrix |
|
A delimiter character for arrays and matrices. | By default array components ('elements' in the non-XML sense) are whitespace-separated. This fails for components with embedded whitespace or missing completely: 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> 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. |
| 160 | dictRef | abundance |
|
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 |
| 161 | dictRef | action |
|
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 |
| 162 | dictRef | actionList |
|
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 |
| 163 | dictRef | amount |
|
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 |
| 164 | dictRef | angle |
|
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 |
| 165 | dictRef | arg |
|
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 |
| 166 | dictRef | array |
|
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 |
| 167 | dictRef | atom |
|
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 |
| 168 | dictRef | atomArray |
|
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 |
| 169 | dictRef | atomicBasisFunction |
|
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 |
| 170 | dictRef | atomParity |
|
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 |
| 171 | dictRef | atomSet |
|
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 |
| 172 | dictRef | atomType |
|
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 |
| 173 | dictRef | atomTypeList |
|
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 |
| 174 | dictRef | band |
|
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 |
| 175 | dictRef | bandList |
|
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 |
| 176 | dictRef | basisSet |
|
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 |
| 177 | dictRef | bond |
|
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 |
| 178 | dictRef | bondArray |
|
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 |
| 179 | dictRef | bondSet |
|
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 |
| 180 | dictRef | bondStereo |
|
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 |
| 181 | dictRef | bondType |
|
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 |
| 182 | dictRef | bondTypeList |
|
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 |
| 183 | dictRef | cml |
|
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 |
| 184 | dictRef | conditionList |
|
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 |
| 185 | dictRef | crystal |
|
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 |
| 186 | dictRef | dictionary |
|
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 |
| 187 | dictRef | eigen |
|
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 |
| 188 | dictRef | electron |
|
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 |
| 189 | dictRef | enumeration |
|
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 |
| 190 | dictRef | expression |
|
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 |
| 191 | dictRef | formula |
|
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 |
| 192 | dictRef | gradient |
|
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 |
| 193 | dictRef | identifier |
|
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 |
| 194 | dictRef | isotope |
|
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 |
| 195 | dictRef | isotopeList |
|
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 |
| 196 | dictRef | label |
|
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 |
| 197 | dictRef | lattice |
|
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 |
| 198 | dictRef | latticeVector |
|
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 |
| 199 | dictRef | length |
|
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 |
| 200 | dictRef | line3 |
|
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 |
| 201 | dictRef | link |
|
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 |
| 202 | dictRef | 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 |
| 203 | dictRef | map |
|
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 |
| 204 | dictRef | matrix |
|
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 |
| 205 | dictRef | mechanism |
|
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 |
| 206 | dictRef | mechanismComponent |
|
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 |
| 207 | dictRef | metadata |
|
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 |
| 208 | dictRef | metadataList |
|
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 |
| 209 | dictRef | module |
|
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 |
| 210 | dictRef | molecule |
|
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 |
| 211 | dictRef | name |
|
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 |
| 212 | dictRef | object |
|
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 |
| 213 | dictRef | observation |
|
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 |
| 214 | dictRef | operator |
|
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 |
| 215 | dictRef | parameter |
|
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 |
| 216 | dictRef | parameterList |
|
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 |
| 217 | dictRef | particle |
|
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 |
| 218 | dictRef | peak |
|
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 |
| 219 | dictRef | peakGroup |
|
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 |
| 220 | dictRef | peakList |
|
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 |
| 221 | dictRef | plane3 |
|
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 |
| 222 | dictRef | point3 |
|
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 |
| 223 | dictRef | potential |
|
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 |
| 224 | dictRef | potentialForm |
|
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 |
| 225 | dictRef | potentialList |
|
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 |
| 226 | dictRef | product |
|
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 |
| 227 | dictRef | productList |
|
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 |
| 228 | dictRef | property |
|
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 |
| 229 | dictRef | propertyList |
|
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 |
| 230 | dictRef | reactant |
|
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 |
| 231 | dictRef | reactantList |
|
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 |
| 232 | dictRef | reaction |
|
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 |
| 233 | dictRef | reactionList |
|
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 |
| 234 | dictRef | reactionScheme |
|
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 |
| 235 | dictRef | reactionStepList |
|
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 |
| 236 | dictRef | reactiveCentre |
|
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 |
| 237 | dictRef | region |
|
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 |
| 238 | dictRef | sample |
|
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 |
| 239 | dictRef | scalar |
|
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 |
| 240 | dictRef | spectator |
|
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 |
| 241 | dictRef | spectatorList |
|
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 |
| 242 | dictRef | spectrum |
|
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 |
| 243 | dictRef | spectrumData |
|
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 |
| 244 | dictRef | spectrumList |
|
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 |
| 245 | dictRef | sphere3 |
|
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 |
| 246 | dictRef | stmml |
|
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 |
| 247 | dictRef | substance |
|
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 |
| 248 | dictRef | substanceList |
|
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 |
| 249 | dictRef | symmetry |
|
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 |
| 250 | dictRef | system |
|
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 |
| 251 | dictRef | table |
|
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 |
| 252 | dictRef | torsion |
|
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 |
| 253 | dictRef | transitionState |
|
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 |
| 254 | dictRef | unitList |
|
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 |
| 255 | dictRef | vector3 |
|
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 |
| 256 | dictRef | xaxis |
|
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 |
| 257 | dictRef | yaxis |
|
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 |
| 258 | dictRef | zMatrix |
|
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 |
| 259 | dimensionality | system |
|
Dimensionality of a coordinate system. | |
| 260 | dimensionBasis | dimension |
|
The basis of the dimension. | Normally taken from the seven SI types but possibly expandable. |
| 261 | elementType | atom |
|
The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 262 | elementType | isotope |
|
The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 263 | elementTypeArray | atomArray |
|
The identity of a chemical element | Normally mandatory on _atom_, _isotope_, etc. |
| 264 | errorBasis | angle |
|
Basis of the error estimate | |
| 265 | errorBasis | array |
|
Basis of the error estimate | |
| 266 | errorBasis | length |
|
Basis of the error estimate | |
| 267 | errorBasis | matrix |
|
Basis of the error estimate | |
| 268 | errorBasis | scalar |
|
Basis of the error estimate | |
| 269 | errorBasis | torsion |
|
Basis of the error estimate | |
| 270 | errorValue | angle |
|
Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 271 | errorValue | length |
|
Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 272 | errorValue | scalar |
|
Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 273 | errorValue | torsion |
|
Value of the error | Reports the author's estimate of the error in a scalar value. Only meaningful for dataTypes mapping to real numbers |
| 274 | errorValueArray | array |
|
Array of error values | Reports the author's estimate of the error in an array of values. Only meaningful for dataTypes mapping to real numbers |
| 275 | errorValueArray | matrix |
|
Array of error values | Reports the author's estimate of the error in an array of values. Only meaningful for dataTypes mapping to real numbers |
| 276 | formalCharge | atom |
|
The formalCharge on the object | 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. |
| 277 | formalCharge | formula |
This allows a charge to be added to the formula
|
The formalCharge on the object | 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. |
| 278 | formalCharge | molecule |
|
The formalCharge on the object | 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. |
| 279 | formalChargeArray | atomArray |
|
An array of formalCharges | 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. |
| 280 | format | spectrum |
|
Format of a spectrum | The data structure of the spectrum. (Not the format of the data). This describes how the data structure is to be interpreted. |
| 281 | formula | molecule |
|
Simple chemical formula | |
| 282 | fractionDigits | entry |
|
Number of digits after the point | |
| 283 | from | link |
|
The base of a link. | |
| 284 | from | map |
|
The base of a link. | |
| 285 | ft | spectrum |
|
Domain of an FT spectrum | Indicates whether a spectrum is raw FID or has been transformed |
| 286 | href | dictionary |
|
address of a resource | 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. |
| 287 | href | link |
The target of the (locator) link, outside the document.
|
address of a resource | 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. |
| 288 | href | relatedEntry |
The related entry.
|
address of a resource | 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. |
| 289 | href | unitList |
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.
|
address of a resource | 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. |
| 290 | hydrogenCount | atom |
|
Number of hydrogens | 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. |
| 291 | hydrogenCountArray | atomArray |
|
Array of hydrogenCounts | 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. |
| 292 | id | abundance |
|
An attribute providing a unique ID for an element. | |
| 293 | id | action |
|
An attribute providing a unique ID for an element. | |
| 294 | id | actionList |
|
An attribute providing a unique ID for an element. | |
| 295 | id | alternative |
|
An attribute providing a unique ID for an element. | |
| 296 | id | amount |
|
An attribute providing a unique ID for an element. | |
| 297 | id | angle |
|
An attribute providing a unique ID for an element. | |
| 298 | id | arg |
|
An attribute providing a unique ID for an element. | |
| 299 | id | array |
|
An attribute providing a unique ID for an element. | |
| 300 | id | atom |
|
An attribute providing a unique ID for an element. | |
| 301 | id | atomArray |
|
An attribute providing a unique ID for an element. | |
| 302 | id | atomicBasisFunction |
|
An attribute providing a unique ID for an element. | |
| 303 | id | atomParity |
|
An attribute providing a unique ID for an element. | |
| 304 | id | atomSet |
|
An attribute providing a unique ID for an element. | |
| 305 | id | atomType |
|
An attribute providing a unique ID for an element. | |
| 306 | id | atomTypeList |
|
An attribute providing a unique ID for an element. | |
| 307 | id | band |
|
An attribute providing a unique ID for an element. | |
| 308 | id | bandList |
|
An attribute providing a unique ID for an element. | |
| 309 | id | basisSet |
|
An attribute providing a unique ID for an element. | |
| 310 | id | bond |
|
An attribute providing a unique ID for an element. | |
| 311 | id | bondArray |
|
An attribute providing a unique ID for an element. | |
| 312 | id | bondSet |
|
An attribute providing a unique ID for an element. | |
| 313 | id | bondStereo |
|
An attribute providing a unique ID for an element. | |
| 314 | id | bondType |
|
An attribute providing a unique ID for an element. | |
| 315 | id | bondTypeList |
|
An attribute providing a unique ID for an element. | |
| 316 | id | cml |
|
An attribute providing a unique ID for an element. | |
| 317 | id | conditionList |
|
An attribute providing a unique ID for an element. | |
| 318 | id | crystal |
|
An attribute providing a unique ID for an element. | |
| 319 | id | description |
|
An attribute providing a unique ID for an element. | |
| 320 | id | dictionary |
|
An attribute providing a unique ID for an element. | |
| 321 | id | dimension |
|
An attribute providing a unique ID for an element. | |
| 322 | id | documentation |
|
An attribute providing a unique ID for an element. | |
| 323 | id | eigen |
|
An attribute providing a unique ID for an element. | |
| 324 | id | electron |
|
An attribute providing a unique ID for an element. | |
| 325 | id | entry |
|
An attribute providing a unique ID for an element. | |
| 326 | id | expression |
|
An attribute providing a unique ID for an element. | |
| 327 | id | formula |
|
An attribute providing a unique ID for an element. | |
| 328 | id | gradient |
|
An attribute providing a unique ID for an element. | |
| 329 | id | identifier |
|
An attribute providing a unique ID for an element. | |
| 330 | id | isotope |
|
An attribute providing a unique ID for an element. | |
| 331 | id | isotopeList |
|
An attribute providing a unique ID for an element. | |
| 332 | id | label |
|
An attribute providing a unique ID for an element. | |
| 333 | id | lattice |
|
An attribute providing a unique ID for an element. | |
| 334 | id | latticeVector |
|
An attribute providing a unique ID for an element. | |
| 335 | id | length |
|
An attribute providing a unique ID for an element. | |
| 336 | id | line3 |
|
An attribute providing a unique ID for an element. | |
| 337 | id | link |
|
An attribute providing a unique ID for an element. | |
| 338 | id | list |
|
An attribute providing a unique ID for an element. | |
| 339 | id | map |
|
An attribute providing a unique ID for an element. | |
| 340 | id | matrix |
|
An attribute providing a unique ID for an element. | |
| 341 | id | mechanism |
|
An attribute providing a unique ID for an element. | |
| 342 | id | mechanismComponent |
|
An attribute providing a unique ID for an element. | |
| 343 | id | metadata |
|
An attribute providing a unique ID for an element. | |
| 344 | id | metadataList |
|
An attribute providing a unique ID for an element. | |
| 345 | id | module |
|
An attribute providing a unique ID for an element. | |
| 346 | id | molecule |
|
An attribute providing a unique ID for an element. | |
| 347 | id | name |
|
An attribute providing a unique ID for an element. | |
| 348 | id | object |
|
An attribute providing a unique ID for an element. | |
| 349 | id | observation |
|
An attribute providing a unique ID for an element. | |
| 350 | id | operator |
|
An attribute providing a unique ID for an element. | |
| 351 | id | parameter |
|
An attribute providing a unique ID for an element. | |
| 352 | id | parameterList |
|
An attribute providing a unique ID for an element. | |
| 353 | id | particle |
|
An attribute providing a unique ID for an element. | |
| 354 | id | peak |
|
An attribute providing a unique ID for an element. | |
| 355 | id | peakGroup |
|
An attribute providing a unique ID for an element. | |
| 356 | id | peakList |
|
An attribute providing a unique ID for an element. | |
| 357 | id | plane3 |
|
An attribute providing a unique ID for an element. | |
| 358 | id | point3 |
|
An attribute providing a unique ID for an element. | |
| 359 | id | potential |
|
An attribute providing a unique ID for an element. | |
| 360 | id | potentialForm |
|
An attribute providing a unique ID for an element. | |
| 361 | id | potentialList |
|
An attribute providing a unique ID for an element. | |
| 362 | id | product |
|
An attribute providing a unique ID for an element. | |
| 363 | id | productList |
|
An attribute providing a unique ID for an element. | |
| 364 | id | property |
|
An attribute providing a unique ID for an element. | |
| 365 | id | propertyList |
|
An attribute providing a unique ID for an element. | |
| 366 | id | reactant |
|
An attribute providing a unique ID for an element. | |
| 367 | id | reactantList |
|
An attribute providing a unique ID for an element. | |
| 368 | id | reaction |
|
An attribute providing a unique ID for an element. | |
| 369 | id | reactionList |
|
An attribute providing a unique ID for an element. | |
| 370 | id | reactionScheme |
|
An attribute providing a unique ID for an element. | |
| 371 | id | reactionStepList |
|
An attribute providing a unique ID for an element. | |
| 372 | id | reactiveCentre |
|
An attribute providing a unique ID for an element. | |
| 373 | id | region |
|
An attribute providing a unique ID for an element. | |
| 374 | id | sample |
|
An attribute providing a unique ID for an element. | |
| 375 | id | scalar |
|
An attribute providing a unique ID for an element. | |
| 376 | id | spectator |
|
An attribute providing a unique ID for an element. | |
| 377 | id | spectatorList |
|
An attribute providing a unique ID for an element. | |
| 378 | id | spectrum |
|
An attribute providing a unique ID for an element. | |
| 379 | id | spectrumData |
|
An attribute providing a unique ID for an element. | |
| 380 | id | spectrumList |
|
An attribute providing a unique ID for an element. | |
| 381 | id | sphere3 |
|
An attribute providing a unique ID for an element. | |
| 382 | id | stmml |
|
An attribute providing a unique ID for an element. | |
| 383 | id | substance |
|
An attribute providing a unique ID for an element. | |
| 384 | id | substanceList |
|
An attribute providing a unique ID for an element. | |
| 385 | id | symmetry |
|
An attribute providing a unique ID for an element. | |
| 386 | id | system |
|
An attribute providing a unique ID for an element. | |
| 387 | id | table |
|
An attribute providing a unique ID for an element. | |
| 388 | id | torsion |
|
An attribute providing a unique ID for an element. | |
| 389 | id | transitionState |
|
An attribute providing a unique ID for an element. | |
| 390 | id | unit |
|
An attribute providing a unique ID for an element. | |
| 391 | id | unitList |
|
An attribute providing a unique ID for an element. | |
| 392 | id | unitType |
|
An attribute providing a unique ID for an element. | |
| 393 | id | vector3 |
|
An attribute providing a unique ID for an element. | |
| 394 | id | xaxis |
|
An attribute providing a unique ID for an element. | |
| 395 | id | yaxis |
|
An attribute providing a unique ID for an element. | |
| 396 | id | zMatrix |
|
An attribute providing a unique ID for an element. | |
| 397 | integral | peak |
|
Area under a peak | Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be used |
| 398 | integral | peakGroup |
|
Area under a peak | Unfortunately units are usually arbitrary and not related to the x- and y- axis units, and in this case _peakUnits_ should be used |
| 399 | irreducibleRepresentation | symmetry |
|
A symmetry species. | No fixed semantics, though we may provide a controlled-extensible list in the future. |
| 400 | isotope | atom |
|
The isotope for an element | A real number describing the isotope. Probably obsolete |
| 401 | isotopeListRef | atom |
|
Reference to a description of the isotopic composition of an atom. | |
| 402 | isotopeNumber | atom |
|
The integer number for an isotope. | The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef). |
| 403 | isotopeNumber | isotope |
|
The integer number for an isotope. | The number representing the isotope. By default it does not point to a fuller description of the isotope (use isotopeRef). |
| 404 | isotopeRef | atom |
|
Reference to a fuller description of the isotope. | |
| 405 | kpoint | band |
|
The k vector | The k-vector with 3 components |
| 406 | l | atomicBasisFunction |
|
Secondary quantum number | 0, 1, etc. |
| 407 | label | band |
|
A label | 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 |
| 408 | latticeType | lattice |
|
The primitivity of a lattice. | |
| 409 | length | entry |
|
Length of a scalar | Probably will be replaced with xsd:schema tools |
| 410 | linkType | link |
|
The type of the link. | |
| 411 | lm | atomicBasisFunction |
|
symbolic represention of l amd m | s, p, px, dxy, dx2y2, f, etc. |
| 412 | m | atomicBasisFunction |
|
Azimuthal quantum number | -1, 0, 1, etc. |
| 413 | matrixType | matrix |
|
Type of matrix. | Mainly square, but extensible through the _xsd:union_ mechanism |
| 414 | max | abundance |
|
Maximum value allowed for an element or attribute. | |
| 415 | max | angle |
|
Maximum value allowed for an element or attribute. | |
| 416 | max | length |
|
Maximum value allowed for an element or attribute. | |
| 417 | max | scalar |
|
Maximum value allowed for an element or attribute. | |
| 418 | max | torsion |
|
Maximum value allowed for an element or attribute. | |
| 419 | maxExclusive | entry |
|
maximum excelusive value | by analogy with xsd:schema |
| 420 | maxInclusive | entry |
|
minimum inclusive value | by analogy with xsd:schema |
| 421 | maxLength | entry |
|
maximum length of a scalar | by analogy with xsd:schema |
| 422 | maxValueArray | array |
|
Maximum values for numeric _matrix_ or _array_ | A whitespace-separated list of the same length as the array in the parent element |
| 423 | maxValueArray | matrix |
|
Maximum values for numeric _matrix_ or _array_ | A whitespace-separated list of the same length as the array in the parent element |
| 424 | measurement | spectrum |
|
Type of spectral measurement | 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. |
| 425 | metadataType | metadata |
|
The metadata type. | |
| 426 | min | abundance |
|
The minimum value allowed for an element or attribute. | |
| 427 | min | angle |
|
The minimum value allowed for an element or attribute. | |
| 428 | min | length |
|
The minimum value allowed for an element or attribute. | |
| 429 | min | scalar |
|
The minimum value allowed for an element or attribute. | |
| 430 | min | torsion |
|
The minimum value allowed for an element or attribute. | |
| 431 | minExclusive | entry |
|
minimum exclusive value | by analogy with xsd:schema |
| 432 | minInclusive | entry |
|
minimum inclusive value | by analogy with xsd:schema |
| 433 | minLength | entry |
|
minimum length of a scalar | by analogy with xsd:schema |
| 434 | minValueArray | array |
|
Minimum values for numeric _matrix_ or _array_ | A whitespace-separated lists of the same length as the array in the parent element |
| 435 | minValueArray | matrix |
|
Minimum values for numeric _matrix_ or _array_ | A whitespace-separated lists of the same length as the array in the parent element |
| 436 | moleculeRef | spectrum |
The molecule to which the spectrum refers
|
A reference to a molecule. | Used by spectrum, etc. |
| 437 | moleculeRef | spectrumList |
|
A reference to a molecule. | Used by spectrum, etc. |
| 438 | multiplierToData | xaxis |
|
The scale by which to multiply the raw data | The scale is applied *before* adding the constant. |
| 439 | multiplierToData | yaxis |
|
The scale by which to multiply the raw data | The scale is applied *before* adding the constant. |
| 440 | multiplierToSI | unit |
|
Multiplier to generate SI equivalent. | 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 units |
| 441 | n | atomicBasisFunction |
|
Principal quantum number | 1, 2, 3, etc. |
| 442 | name | arg |
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 443 | name | atomType |
The name will usually be namespaced as 'gulp:si', 'tripos:c.3', etc. It must occur except for atomType/@ref
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 444 | name | bondType |
The name will usually be namespaced as 'gulp:si', 'tripos:c.3', etc. It must occur except when the ref attribute is given
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 445 | name | parameter |
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 446 | name | potentialForm |
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 447 | name | unit |
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 448 | name | unitType |
|
Name of the object | A string by which the object is known. Often a required attribute. The may or may not be a semi-controlled vocabulary. |
| 449 | number | symmetry |
The rotational symmetry number
Used for calculation of entropy, etc.
|
The rotational symmetry number | Used for calculation of entropy, etc. |
| 450 | objectClass | description |
|
The class of an object | The type of this information. This is not controlled, but examples might include: label summary note usage qualifier It might be used to control display or XSL filtering. |
| 451 | objectClass | label |
|
The class of an object | The type of this information. This is not controlled, but examples might include: label summary note usage qualifier It might be used to control display or XSL filtering. |
| 452 | occupancy | atom |
|
Occupancy for an atom | Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formaula from the atoms. |
| 453 | occupancyArray | atomArray |
|
Array of occupancies | Normally only found in crystallography. Defaults to 1.0. The occupancy is required to calculate the molecular formula from the atoms. |
| 454 | order | bond |
|
The order of the bond. | There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations. |
| 455 | orderArray | bondArray |
|
The order of the bond. | There is NO default. This order is for bookkeeping only and is not related to length, QM calculations or other experimental or theoretical calculations. |
| 456 | parentSI | unit |
|
A dictRef like reference to the id of the parent SI unit. | 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. |
| 457 | pattern | entry |
|
Pattern constraint | Based on xsd:schema |
| 458 | peakHeight | peak |
|
Height of a peak | For 1-dimensional data (e.g. y vs x) hould use the same units as the appropriate axis (e.g. y). |
| 459 | peakHeight | peakGroup |
|
Height of a peak | For 1-dimensional data (e.g. y vs x) hould use the same units as the appropriate axis (e.g. y). |
| 460 | peakMultiplicity | peak |
|
Multiplicity of a peak | Uses a semi-controlled vocabulary |
| 461 | peakMultiplicity | peakGroup |
|
Multiplicity of a peak | Uses a semi-controlled vocabulary |
| 462 | peakShape | peak |
|
Shape of a peak | Semi-controlled vocabulary such as broad or sharp |
| 463 | peakShape | peakGroup |
|
Shape of a peak | Semi-controlled vocabulary such as broad or sharp |
| 464 | peakUnits | peak |
|
Units for a peak or peak integral | For 2-dimensional spectra the units represent th 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. |
| 465 | peakUnits | peakGroup |
|
Units for a peak or peak integral | For 2-dimensional spectra the units represent th 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. |
| 466 | periodic | latticeVector |
|
Is the axis periodic | 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 |
| 467 | periodicity | system |
|
Periodicity of the system. | |
| 468 | pointGroup | symmetry |
|
A point group. | No fixed semantics, though Schoenflies is recommended over Hermann-Mauguin. We may provide a controlled-extensible list in the future. |
| 469 | power | dimension |
|
The power to which a dimension should be raised. | Normally an integer. Must be included, even if unity. |
| 470 | preserve | dimension |
|
Is the dimension preserved during algebra | |
| 471 | reactionRole | reaction |
|
Role of the reaction | |
| 472 | reactionRole | reactionScheme |
|
Role of the reaction | |
| 473 | reactionType | reaction |
|
Type of the reaction | |
| 474 | reactionType | reactionScheme |
|
Type of the reaction | |
| 475 | ref | action |
|
A reference to an element of given type. | ref 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. |
| 476 | ref | angle |
|
A reference to an element of given type. | ref 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. |
| 477 | ref | arg |
|
A reference to an element of given type. | ref 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. |
| 478 | ref | array |
|
A reference to an element of given type. | ref 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. |
| 479 | ref | atom |
|
A reference to an element of given type. | ref 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. |
| 480 | ref | atomArray |
|
A reference to an element of given type. | ref 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. |
| 481 | ref | atomTypeList |
|
A reference to an element of given type. | ref 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. |
| 482 | ref | basisSet |
|
A reference to an element of given type. | ref 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. |
| 483 | ref | bond |
|
A reference to an element of given type. | ref 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. |
| 484 | ref | bondType |
|
A reference to an element of given type. | ref 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. |
| 485 | ref | bondTypeList |
|
A reference to an element of given type. | ref 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. |
| 486 | ref | conditionList |
|
A reference to an element of given type. | ref 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. |
| 487 | ref | electron |
|
A reference to an element of given type. | ref 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. |
| 488 | ref | isotope |
|
A reference to an element of given type. | ref 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. |
| 489 | ref | isotopeList |
|
A reference to an element of given type. | ref 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. |
| 490 | ref | length |
|
A reference to an element of given type. | ref 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. |
| 491 | ref | link |
|
A reference to an element of given type. | ref 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. |
| 492 | ref | molecule |
|
A reference to an element of given type. | ref 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. |
| 493 | ref | parameter |
|
A reference to an element of given type. | ref 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. |
| 494 | ref | parameterList |
|
A reference to an element of given type. | ref 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. |
| 495 | ref | peak |
|
A reference to an element of given type. | ref 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. |
| 496 | ref | peakGroup |
|
A reference to an element of given type. | ref 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. |
| 497 | ref | peakList |
|
A reference to an element of given type. | ref 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. |
| 498 | ref | product |
|
A reference to an element of given type. | ref 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. |
| 499 | ref | productList |
|
A reference to an element of given type. | ref 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. |
| 500 | ref | property |
|
A reference to an element of given type. | ref 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. |
| 501 | ref | propertyList |
|
A reference to an element of given type. | ref 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. |
| 502 | ref | reactant |
|
A reference to an element of given type. | ref 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. |
| 503 | ref | reactantList |
|
A reference to an element of given type. | ref 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. |
| 504 | ref | reaction |
|
A reference to an element of given type. | ref 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. |
| 505 | ref | reactionList |
|
A reference to an element of given type. | ref 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. |
| 506 | ref | reactionScheme |
|
A reference to an element of given type. | ref 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. |
| 507 | ref | reactionStepList |
|
A reference to an element of given type. | ref 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. |
| 508 | ref | sample |
|
A reference to an element of given type. | ref 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. |
| 509 | ref | spectrum |
|
A reference to an element of given type. | ref 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. |
| 510 | ref | spectrumData |
|
A reference to an element of given type. | ref 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. |
| 511 | ref | spectrumList |
|
A reference to an element of given type. | ref 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. |
| 512 | ref | substance |
|
A reference to an element of given type. | ref 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. |
| 513 | ref | substanceList |
|
A reference to an element of given type. | ref 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. |
| 514 | ref | torsion |
|
A reference to an element of given type. | ref 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. |
| 515 | ref | xaxis |
|
A reference to an element of given type. | ref 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. |
| 516 | ref | yaxis |
|
A reference to an element of given type. | ref 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. |
| 517 | regionRefs | region |
|
A list of regions creating a union | 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. |
| 518 | relatedEntryType | relatedEntry |
|
Type of relatedEntry | Type represents a the type of relationship in a relatedEntry element. |
| 519 | role | appinfo |
Allows a processor to inspect the role of the appinfo and process accordingly.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 520 | role | atom |
This can be used to describe the purpose of atoms whose _elementType_s are __dummy__ or __locant__. Vocabulary not controlled.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 521 | role | basisSet |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 522 | role | conditionList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 523 | role | link |
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.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 524 | role | module |
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.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 525 | role | molecule |
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. |
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 526 | role | parameter |
Used to define concepts such as independent and dependent variables |
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 527 | role | parameterList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 528 | role | product |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 529 | role | productList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 530 | role | property |
Semantics are not yet controlled but could include thermochemistry, kinetics or other common properties. |
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 531 | role | propertyList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 532 | role | reactant |
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.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 533 | role | reactantList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 534 | role | spectator |
No controlled vocabulary. Examples could be "host", "hydrophobic ligand", "charge-stabilizer", etc..
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 535 | role | substance |
role 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.
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 536 | role | substanceList |
|
Role of the object | How the object functions or its position in the architecture. No controlled vocabulary |
| 537 | rows | entry |
|
Number of rows. | |
| 538 | rows | matrix |
|
Number of rows. | |
| 539 | rows | table |
|
Number of rows. | |
| 540 | scheme | reactionStepList |
|
The sequence of steps in a reactionList | 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. |
| 541 | serial | module |
|
Serial number or other id | |
| 542 | size | array |
|
The size of an array or matrix | |
| 543 | size | atomSet |
|
The size of an array or matrix | |
| 544 | size | bondSet |
|
The size of an array or matrix | |
| 545 | spaceGroup | symmetry |
|
A space group. | No fixed semantics, though Hermann-Mauguin or Hall is recommended over Schoenflies. We may provide a controlled-extensible list in the future. |
| 546 | spaceType | lattice |
|
The spaceType of the lattice. | |
| 547 | spectrumType | spectrum |
|
The type of the spectrum. | |
| 548 | sphere3 | region |
|
A sphere | Currently describes a region. Any point falling within the sphere or on its surface is within the region |
| 549 | spin | isotope |
|
The spin of a system | Supports fractional values. Currently the spin of a nucleus. The normal fraction representing the spin of the isotope. |
| 550 | spinMultiplicity | molecule |
|
Spin multiplicity | 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) |
| 551 | state | product |
|
The physical state of the substance. | No fixed semantics or default. |
| 552 | state | property |
|
The physical state of the substance. | No fixed semantics or default. |
| 553 | state | reactant |
|
The physical state of the substance. | No fixed semantics or default. |
| 554 | state | reaction |
|
The physical state of the substance. | No fixed semantics or default. |
| 555 | state | reactionScheme |
|
The physical state of the substance. | No fixed semantics or default. |
| 556 | state | sample |
|
The physical state of the substance. | No fixed semantics or default. |
| 557 | state | spectrum |
Although this may also be contained in the sample element it is useful to state it here. No default.
|
The physical state of the substance. | No fixed semantics or default. |
| 558 | state | substance |
|
The physical state of the substance. | No fixed semantics or default. |
| 559 | substanceListType | substanceList |
|
Type of the substanceList: | Extension is allowed through the "other" value. |
| 560 | symbol | atomicBasisFunction |
|
A symbol | Currently only used on _atomicBasisFunction_. Example "s" |
| 561 | symmetryOriented | molecule |
|
Is the molecule oriented to the symmetry. | 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 |
| 562 | tautomeric | identifier |
|
Indicates whether the structure is a tautomer | |
| 563 | term | entry |
|
A term in a dictionary | The term should be a noun or nounal phrase, with a separate definition and further description |
| 564 | title | abundance |
|
A title on an element. | No controlled value. |
| 565 | title | action |
|
A title on an element. | No controlled value. |
| 566 | title | actionList |
|
A title on an element. | No controlled value. |
| 567 | title | amount |
|
A title on an element. | No controlled value. |
| 568 | title | angle |
|
A title on an element. | No controlled value. |
| 569 | title | arg |
|
A title on an element. | No controlled value. |
| 570 | title | array |
|
A title on an element. | No controlled value. |
| 571 | title | atom |
|
A title on an element. | No controlled value. |
| 572 | title | atomArray |
|
A title on an element. | No controlled value. |
| 573 | title | atomicBasisFunction |
|
A title on an element. | No controlled value. |
| 574 | title | atomParity |
|
A title on an element. | No controlled value. |
| 575 | title | atomSet |
|
A title on an element. | No controlled value. |
| 576 | title | atomType |
|
A title on an element. | No controlled value. |
| 577 | title | atomTypeList |
|
A title on an element. | No controlled value. |
| 578 | title | band |
|
A title on an element. | No controlled value. |
| 579 | title | bandList |
|
A title on an element. | No controlled value. |
| 580 | title | basisSet |
|
A title on an element. | No controlled value. |
| 581 | title | bond |
|
A title on an element. | No controlled value. |
| 582 | title | bondArray |
|
A title on an element. | No controlled value. |
| 583 | title | bondSet |
|
A title on an element. | No controlled value. |
| 584 | title | bondStereo |
|
A title on an element. | No controlled value. |
| 585 | title | bondType |
|
A title on an element. | No controlled value. |
| 586 | title | bondTypeList |
|
A title on an element. | No controlled value. |
| 587 | title | cml |
|
A title on an element. | No controlled value. |
| 588 | title | conditionList |
|
A title on an element. | No controlled value. |
| 589 | title | crystal |
|
A title on an element. | No controlled value. |
| 590 | title | dictionary |
|
A title on an element. | No controlled value. |
| 591 | title | eigen |
|
A title on an element. | No controlled value. |
| 592 | title | electron |
|
A title on an element. | No controlled value. |
| 593 | title | entry |
|
A title on an element. | No controlled value. |
| 594 | title | expression |
|
A title on an element. | No controlled value. |
| 595 | title | formula |
|
A title on an element. | No controlled value. |
| 596 | title | gradient |
|
A title on an element. | No controlled value. |
| 597 | title | identifier |
|
A title on an element. | No controlled value. |
| 598 | title | isotope |
|
A title on an element. | No controlled value. |
| 599 | title | isotopeList |
|
A title on an element. | No controlled value. |
| 600 | title | lattice |
|
A title on an element. | No controlled value. |
| 601 | title | latticeVector |
|
A title on an element. | No controlled value. |
| 602 | title | length |
|
A title on an element. | No controlled value. |
| 603 | title | line3 |
|
A title on an element. | No controlled value. |
| 604 | title | link |
|
A title on an element. | No controlled value. |
| 605 | title | list |
|
A title on an element. | No controlled value. |
| 606 | title | map |
|
A title on an element. | No controlled value. |
| 607 | title | matrix |
|
A title on an element. | No controlled value. |
| 608 | title | mechanism |
|
A title on an element. | No controlled value. |
| 609 | title | mechanismComponent |
|
A title on an element. | No controlled value. |
| 610 | title | metadata |
|
A title on an element. | No controlled value. |
| 611 | title | metadataList |
|
A title on an element. | No controlled value. |
| 612 | title | module |
|
A title on an element. | No controlled value. |
| 613 | title | molecule |
|
A title on an element. | No controlled value. |
| 614 | title | object |
|
A title on an element. | No controlled value. |
| 615 | title | observation |
|
A title on an element. | No controlled value. |
| 616 | title | operator |
|
A title on an element. | No controlled value. |
| 617 | title | parameter |
|
A title on an element. | No controlled value. |
| 618 | title | parameterList |
|
A title on an element. | No controlled value. |
| 619 | title | particle |
|
A title on an element. | No controlled value. |
| 620 | title | peak |
|
A title on an element. | No controlled value. |
| 621 | title | peakGroup |
|
A title on an element. | No controlled value. |
| 622 | title | peakList |
|
A title on an element. | No controlled value. |
| 623 | title | plane3 |
|
A title on an element. | No controlled value. |
| 624 | title | point3 |
|
A title on an element. | No controlled value. |
| 625 | title | potential |
|
A title on an element. | No controlled value. |
| 626 | title | potentialForm |
|
A title on an element. | No controlled value. |
| 627 | title | potentialList |
|
A title on an element. | No controlled value. |
| 628 | title | product |
|
A title on an element. | No controlled value. |
| 629 | title | productList |
|
A title on an element. | No controlled value. |
| 630 | title | property |
|
A title on an element. | No controlled value. |
| 631 | title | propertyList |
|
A title on an element. | No controlled value. |
| 632 | title | reactant |
|
A title on an element. | No controlled value. |
| 633 | title | reactantList |
|
A title on an element. | No controlled value. |
| 634 | title | reaction |
|
A title on an element. | No controlled value. |
| 635 | title | reactionList |
|
A title on an element. | No controlled value. |
| 636 | title | reactionScheme |
|
A title on an element. | No controlled value. |
| 637 | title | reactionStepList |
|
A title on an element. | No controlled value. |
| 638 | title | reactiveCentre |
|
A title on an element. | No controlled value. |
| 639 | title | region |
|
A title on an element. | No controlled value. |
| 640 | title | sample |
|
A title on an element. | No controlled value. |
| 641 | title | scalar |
|
A title on an element. | No controlled value. |
| 642 | title | spectator |
|
A title on an element. | No controlled value. |
| 643 | title | spectatorList |
|
A title on an element. | No controlled value. |
| 644 | title | spectrum |
|
A title on an element. | No controlled value. |
| 645 | title | spectrumData |
|
A title on an element. | No controlled value. |
| 646 | title | spectrumList |
|
A title on an element. | No controlled value. |
| 647 | title | sphere3 |
|
A title on an element. | No controlled value. |
| 648 | title | stmml |
|
A title on an element. | No controlled value. |
| 649 | title | substance |
|
A title on an element. | No controlled value. |
| 650 | title | substanceList |
|
A title on an element. | No controlled value. |
| 651 | title | symmetry |
|
A title on an element. | No controlled value. |
| 652 | title | system |
|
A title on an element. | No controlled value. |
| 653 | title | table |
|
A title on an element. | No controlled value. |
| 654 | title | torsion |
|
A title on an element. | No controlled value. |
| 655 | title | transitionState |
|
A title on an element. | No controlled value. |
| 656 | title | unitList |
|
A title on an element. | No controlled value. |
| 657 | title | vector3 |
|
A title on an element. | No controlled value. |
| 658 | title | xaxis |
|
A title on an element. | No controlled value. |
| 659 | title | yaxis |
|
A title on an element. | No controlled value. |
| 660 | title | zMatrix |
|
A title on an element. | No controlled value. |
| 661 | to | link |
|
The target of a link. | |
| 662 | to | map |
|
The target of a link. | |
| 663 | totalDigits | entry |
|
total digits in a scalar | based on xsd:schema |
| 664 | type | action |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 665 | type | actionList |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 666 | type | eigen |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 667 | type | list |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 668 | type | object |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 669 | type | observation |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 670 | type | operator |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 671 | type | particle |
Used in a similar manner to atomType. Examples might be "lonePair", "polarizable Oxygen", etc.
|
Type of the object | A qualifier which may affect the semantics of the object |
| 672 | type | substance |
|
Type of the object | A qualifier which may affect the semantics of the object |
| 673 | units | abundance |
|
Scientific units on an element. | 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. |
| 674 | units | amount |
|
Scientific units on an element. | 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. |
| 675 | units | array |
|
Scientific units on an element. | 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. |
| 676 | units | eigen |
|
Scientific units on an element. | 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. |
| 677 | units | entry |
|
Scientific units on an element. | 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. |
| 678 | units | latticeVector |
|
Scientific units on an element. | 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. |
| 679 | units | length |
|
Scientific units on an element. | 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. |
| 680 | units | line3 |
|
Scientific units on an element. | 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. |
| 681 | units | matrix |
|
Scientific units on an element. | 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. |
| 682 | units | plane3 |
|
Scientific units on an element. | 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. |
| 683 | units | point3 |
|
Scientific units on an element. | 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. |
| 684 | units | scalar |
|
Scientific units on an element. | 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. |
| 685 | units | sphere3 |
|
Scientific units on an element. | 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. |
| 686 | units | table |
|
Scientific units on an element. | 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. |
| 687 | units | torsion |
|
Scientific units on an element. | 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. |
| 688 | units | vector3 |
|
Scientific units on an element. | 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. |
| 689 | unitType | entry |
|
A reference to the type of a unit. | Used in defining the unit and doing symbolic algebra on the dimensionality |
| 690 | unitType | unit |
|
A reference to the type of a unit. | Used in defining the unit and doing symbolic algebra on the dimensionality |
| 691 | value | enumeration |
|
Value of a scalar object | The value must be consistent with the dataType of the object |
| 692 | value | label |
|
Value of a scalar object | The value must be consistent with the dataType of the object |
| 693 | value | parameter |
This is a shorthand for a single scalar value of the parameter. It should only be used with the ref 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?].
|
Value of a scalar object | The value must be consistent with the dataType of the object |
| 694 | version | identifier |
|
The version of the identifier. | |
| 695 | weight | band |
|
Weight of the element | 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). |
| 696 | whiteSpace | entry |
|
whitespace | attached to entry. This may be obsolete |
| 697 | xMax | peak |
|
Maximum yValue | 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. |
| 698 | xMax | peakGroup |
|
Maximum yValue | 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. |
| 699 | xMin | peak |
|
Minimum yValue | 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. |
| 700 | xMin | peakGroup |
|
Minimum yValue | 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. |
| 701 | xUnits | peak |
|
Units for x axis | 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. |
| 702 | xUnits | peakGroup |
|
Units for x axis | 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. |
| 703 | xValue | peak |
|
Value along an x axis | 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. |
| 704 | xValue | peakGroup |
|
Value along an x axis | 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. |
| 705 | xWidth | peak |
|
An unsigned interval along an x axis | 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. |
| 706 | xWidth | peakGroup |
|
An unsigned interval along an x axis | 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. |
| 707 | xy2 | atom |
|
x2 coordinate for an object | 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 objects |
| 708 | xy2Array | atomArray |
|
array of x2 coordinates | 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 objects |
| 709 | xyz3 | atom |
|
group of attributes for arrays of x3 y3 z3 | |
| 710 | xyz3 | particle |
|
group of attributes for arrays of x3 y3 z3 | |
| 711 | xyz3Array | atomArray |
|
group of attributes for arrays of x3 y3 z3 | |
| 712 | xyzFract | atom |
|
group of attributes for xFract yFract zFract | normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur. |
| 713 | xyzFractArray | atomArray |
|
group of attributes for arrays of xFract yFract zFract | normally xFract, yFract and zFract should all be present or absent. If present a _crystal_ element should also occur. |
| 714 | yMax | peak |
|
Maximum yValue | 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. |
| 715 | yMax | peakGroup |
|
Maximum yValue | 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. |
| 716 | yMin | peak |
|
Minimum yValue | 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. |
| 717 | yMin | peakGroup |
|
Minimum yValue | 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. |
| 718 | yUnits | peak |
|
Units for y axis | 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. |
| 719 | yUnits | peakGroup |
|
Units for y axis | 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. |
| 720 | yValue | peak |
|
Value along a y axis | 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. |
| 721 | yValue | peakGroup |
|
Value along a y axis | 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. |
| 722 | yWidth | peak |
|
An unsigned interval along a y axis | 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. |
| 723 | yWidth | peakGroup |
|
An unsigned interval along a y axis | 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. |
| 724 | z | crystal |
|
The number of molecules per cell. | Molecules are defined as the _molecule_ which directly contains the _crystal_ element. |