link 

<h:div class="summary">An internal or external link to other objects.</h:div>
<h:div class="description">
  <h:p>
    <h:b>Semantics are similar to XLink, but simpler and only a subset is implemented.</h:b>This is intended to make the instances easy to create and read, and software relatively easy to implement. The architecture is:</h:p>
  <h:ul>
    <h:li>
      <h:b>A single element (
        <h:tt>link</h:tt>) used for all linking purposes.</h:b>
    </h:li>
    <h:li>
      <h:b>The link types are determined by the
        <h:tt>type</h:tt>attribute and can be:</h:b>.
      <h:ul>
        <h:li>
          <h:b>locator</h:b>. This points to a single target and must carry either a
          <h:tt>ref</h:tt>or
          <h:tt>href</h:tt>attribute.
          <h:tt>locator</h:tt>links are usually children of an extended link.
          <h:li>
            <h:b>arc</h:b>. This is a 1:1 link with both ends (
            <h:tt>from</h:tt>and
            <h:tt>to</h:tt>) defined.</h:li>
          <h:li>
            <h:b>extended</h:b>. This is usually a parent of several locator links and serves to create a grouping of link ends (i.e. a list of references in documents).</h:li>Many-many links can be built up from arcs linking extended elements</h:li>
      </h:ul>
      <h:p>All links can have optional
        <h:tt>role</h:tt>attributes. The semantics of this are not defined; you are encouraged to use a URI as described in the XLink specification.</h:p>
      <h:p>There are two address spaces:</h:p>
      <h:ul>
        <h:li>The
          <h:tt>href</h:tt>attribute on locators behaves in the same way as
          <h:tt>href</h:tt>in HTML and is of type
          <h:tt>xsd:anyURI</h:tt>. Its primary use is to use XPointer to reference elements outside the doc.</h:li>
        <h:li>The
          <h:tt>ref</h:tt>attribute on locators and the
          <h:tt>from</h:tt>and
          <h:tt>to</h:tt>attributes on
          <h:tt>arc</h:tt>s refer to IDs (
          <h:em>without</h:em>the '#' syntax).</h:li>
      </h:ul>
      <h:p>Note: several other specific linking mechanisms are defined elsewhere in STM.
        <h:a href="st.dictRef">dictRef</h:a>should be used to link to dictionaries. There are no required uses of
        <h:tt>link</h:tt>in STMML but we have used it to map atoms, electrons and bonds in reactions in CML</h:p>
    </h:li>
  </h:ul>
  <h:p>
    <h:b>Relation to XLink</h:b>. At present (2002) we are not aware of generic XLink processors from which we would benefit, so the complete implementation brings little extra value. Among the simplifications from Xlink are:</h:p>
  <h:ul>
    <h:li>
      <h:tt>type</h:tt>supports only
      <h:tt>extended</h:tt>,
      <h:tt>locator</h:tt>and
      <h:tt>arc</h:tt>
    </h:li>
    <h:li>
      <h:tt>label</h:tt>is not supported and
      <h:tt>id</h:tt>s are used as targets of links.</h:li>
    <h:li>
      <h:tt>show</h:tt>and
      <h:tt>actuate</h:tt>are not supported.</h:li>
    <h:li>
      <h:tt>xlink:title</h:tt>is not supported (all STM elements can have a
      <h:tt>title</h:tt>attribute).</h:li>
    <h:li>
      <h:tt>xlink:role</h:tt>supports any string (i.e. does not have to be a namespaced resource). This mechanism can, of course, still be used and we shall promote it where STM benefits from it</h:li>
    <h:li>The
      <h:tt>to</h:tt>and
      <h:tt>from</h:tt>attributes point to IDs rather than labels</h:li>
    <h:li>The xlink namespace is not used</h:li>
    <h:li>It is not intended to create independent linkbases, although some collections of links may have this property and stand outside the documents they link to</h:li>
  </h:ul>
</h:div>

Element Information

Model

anyCml | ANY element from ANY namespace OTHER than 'http://www.xml-cml.org/schema' | ANY element from LOCAL namespace 'No Namespace'
Children: anyCml

Attributes

QName Type Fixed Default Use Inheritable Annotation
convention namespaceRefType optional 
<h:div class="summary">A reference to a convention.</h:div>
<h:div class="description">There is no controlled vocabulary for conventions, but the author must ensure that the semantics are openly available and that there are mechanisms for implementation. The convention is inherited by all the subelements, so that a convention for
  <h:tt>molecule</h:tt>would by default extend to its
  <h:tt>bond</h:tt>and
  <h:tt>atom</h:tt>children. This can be overwritten if necessary by an explicit
  <h:tt>convention</h:tt>.
  <h:p>It may be useful to create conventions with namespaces (e.g.
    <h:tt>iupac:name</h:tt>). Use of
    <h:tt>convention</h:tt>will normally require non-STMML semantics, and should be used with caution. We would expect that conventions prefixed with "ISO" would be useful, such as ISO8601 for dateTimes.</h:p>
  <h:p>There is no default, but the conventions of STMML or the related language (e.g. CML) will be assumed.</h:p>
</h:div>
<h:div class="example" id="ex" href="convGroup1.xml"/>
dictRef namespaceRefType optional 
<h:div class="summary">A reference to a dictionary entry.</h:div>
<h:div class="description">Elements in data instances such as _scalar_ may have a
  <h:tt>dictRef</h:tt>attribute to point to an entry in a dictionary. To avoid excessive use of (mutable) filenames and URIs we recommend a namespace prefix, mapped to a namespace URI in the normal manner. In this case, of course, the namespace URI must point to a real XML doc containing _entry_ elements and validated against STMML Schema.
  <h:p>Where there is concern about the dictionary becoming separated from the doc the dictionary entries can be physically included as part of the data instance and the normal XPointer addressing mechanism can be used.</h:p>
  <h:p>This attribute can also be used on _dictionary_ elements to define the namespace prefix</h:p>
</h:div>
<h:div class="example" href="dictRefGroup1.xml"/>
from refType optional 
<h:div class="summary">The base of one or more links.</h:div>
<h:div class="description">On link elements the value is the single id of an element within the doc or context specified in map@fromRef attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'to' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'fromSet'.</h:div>
<h:div class="curation">2005-06-18: updated docs</h:div>
fromContext idType optional 
<h:div class="summary">The context for the 'from' links in a map.</h:div>
<h:div class="description">
  <h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a doc. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p>
  <h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
fromSet idArrayType optional 
<h:div class="summary">A set of ids representing the base of a link.</h:div>
<h:div class="description">
  <h:p>For a partial mapping where a number of 'from' elements are known to link to a number of 'to' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'from' elements and n 'to' elements but that the precise links are unknown. The semantics of the reference are the same as for 'from' and all the elements must be of the same type (which can be specified with 'fromType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'toSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
fromType xmlElementType optional 
<h:div class="summary">The type of the base of a link.</h:div>
<h:div class="description">
  <h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p>
  <h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
href xsd:anyURI optional 
<h:div class="summary">address of a resource.</h:div>
<h:div class="description">Links to another element in the same or other file. For dictionary/@dictRef requires the prefix and the physical URI address to be contained within the same file. We can anticipate that better mechanisms will arise - perhaps through XMLCatalogs. At least it works at present.</h:div>
id idType optional 
<h:div class="summary">A unique ID for an element.</h:div>
<h:div class="description">Id is used for machine identification of elements and in general should not have application semantics. It is similar to the XML ID type as containing only alphanumerics, '_', ',' and '-' and and must start with an alphabetic character. Ids are case sensitive. Ids should be unique within local scope, thus all atoms within a molecule should have unique ids, but separated molecules within a doc (such as a published article) might have identical ids. Software should be able to search local scope (e.g. all atoms within a molecule). However this is under constant review.</h:div>
linkType linkTypeType optional 
<h:div class="summary">The type of the link.</h:div>
ref refType optional 
<h:div class="summary">A reference to an element of given type.</h:div>
<h:div class="description">
  <h:tt>ref</h:tt>modifies an element into a reference to an existing element of that type within the doc. This is similar to a pointer and it can be thought of a strongly typed hyperlink. It may also be used for "subclassing" or "overriding" elements.
  <br xmlns=""/>When referring to an element most of the "data" such as attribute values and element content will be on the full instantiated element. Therefore ref (and possibly id) will normally be the only attributes on the pointing element. However there may be some attributes (title, count, etc.) which have useful semantics, but these are element-specific</h:div>
<h:div class="example" href="refGroup1.xml"/>
role xsd:string optional 
<h:div class="summary">Role of the object.</h:div>
<h:div class="description">How the object functions or its position in the architecture. No controlled vocabulary.</h:div>
title xsd:string optional 
<h:div class="summary">A title on an element.</h:div>
<h:div class="description">No controlled value.</h:div>
<h:div class="example" href="title1.xml"/>
to refType optional 
<h:div class="summary">The target of one or more links.</h:div>
<h:div class="summary">On link elements the value is the single id of an element within the doc or context specified in map@toContext attributes. It must identify the element uniquely. The reserved value 'null' implies that no mapping has been provided for the object(s) in the 'from' attribute. This implies no semantics but may be used by software to keep count of which elements have been mapped. For multiple targets use 'toSet'.</h:div>
<h:div class="curation">2005-06-18: updated docs</h:div>
toContext idType optional 
<h:div class="summary">The context for the 'from' links in a map.</h:div>
<h:div class="description">
  <h:p>A reference to the unique 'id' attribute of an element defining the context for links in a map. This may be required when id attributes may not be unique within a doc. The id should either reference an element uniquely or should be taken as the first ancestor (of the map) with such an id.</h:p>
  <h:p>This is fairly horrid but may be required when documents are assembled without establishing unique ids (e.g. concatenation of files). As an example a map referencing linked atoms in two molecules might use the containing 'reaction' element as its uniquifying context.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
toSet idArrayType optional 
<h:div class="summary">A set of ids representing the base of a link.</h:div>
<h:div class="description">
  <h:p>For a partial mapping where a number of 'to' elements are known to link to a number of 'from' elements it can be useful to aggregate these into a single attribute value. The primary use is to assert that n links exist between a set of n 'to' elements and n 'from' elements but that the precise links are unknown. The semantics of the reference are the same as for 'to' and all the elements must be of the same type (which can be specified with 'toType' either on the link or the containing map). No order information is implied. In general there will be the same number of idRefs in the 'fromSet' and all implicit links will share the same attributes (e.g. 'role'). In many cases the sets will be later split into discrete links thorugh further calculation or experiment (e.g. peak assignment). Sets should never be used as a lazy or concise alternative where the all the links are explicitly known.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
toType xmlElementType optional 
<h:div class="summary">The type of the base of a link.</h:div>
<h:div class="description">
  <h:p>The local tagname of the referenced element (e.g. 'molecule' or 'peakGroup'). This acts as a partial check on the integrity of the link. Software can assume that the referenced element is of a given tytpe and can create an object supporting that type.</h:p>
  <h:p>This attribute can be attached to the 'map' attribute and requires all contained links to be of this type. This can be overridden by a 'toType' attribute on indivdual links, but it may also be useful to split the map into maps od different link types.</h:p>
</h:div>
<h:div class="curation">2005-06-18: created</h:div>
Wildcard: ANY attribute from ANY namespace OTHER than 'http://www.xml-cml.org/schema'

Source 

<xsd:element name="link" id="el.link" substitutionGroup="anyCml">
  <xsd:annotation>
    <xsd:documentation>
      <h:div class="summary">An internal or external link to other objects.</h:div>
      <h:div class="description">
        <h:p>
          <h:b>Semantics are similar to XLink, but simpler and only a subset is implemented.</h:b>This is intended to make the instances easy to create and read, and software relatively easy to implement. The architecture is:</h:p>
        <h:ul>
          <h:li>
            <h:b>A single element (
              <h:tt>link</h:tt>) used for all linking purposes.</h:b>
          </h:li>
          <h:li>
            <h:b>The link types are determined by the
              <h:tt>type</h:tt>attribute and can be:</h:b>.
            <h:ul>
              <h:li>
                <h:b>locator</h:b>. This points to a single target and must carry either a
                <h:tt>ref</h:tt>or
                <h:tt>href</h:tt>attribute.
                <h:tt>locator</h:tt>links are usually children of an extended link.
                <h:li>
                  <h:b>arc</h:b>. This is a 1:1 link with both ends (
                  <h:tt>from</h:tt>and
                  <h:tt>to</h:tt>) defined.</h:li>
                <h:li>
                  <h:b>extended</h:b>. This is usually a parent of several locator links and serves to create a grouping of link ends (i.e. a list of references in documents).</h:li>Many-many links can be built up from arcs linking extended elements</h:li>
            </h:ul>
            <h:p>All links can have optional
              <h:tt>role</h:tt>attributes. The semantics of this are not defined; you are encouraged to use a URI as described in the XLink specification.</h:p>
            <h:p>There are two address spaces:</h:p>
            <h:ul>
              <h:li>The
                <h:tt>href</h:tt>attribute on locators behaves in the same way as
                <h:tt>href</h:tt>in HTML and is of type
                <h:tt>xsd:anyURI</h:tt>. Its primary use is to use XPointer to reference elements outside the doc.</h:li>
              <h:li>The
                <h:tt>ref</h:tt>attribute on locators and the
                <h:tt>from</h:tt>and
                <h:tt>to</h:tt>attributes on
                <h:tt>arc</h:tt>s refer to IDs (
                <h:em>without</h:em>the '#' syntax).</h:li>
            </h:ul>
            <h:p>Note: several other specific linking mechanisms are defined elsewhere in STM.
              <h:a href="st.dictRef">dictRef</h:a>should be used to link to dictionaries. There are no required uses of
              <h:tt>link</h:tt>in STMML but we have used it to map atoms, electrons and bonds in reactions in CML</h:p>
          </h:li>
        </h:ul>
        <h:p>
          <h:b>Relation to XLink</h:b>. At present (2002) we are not aware of generic XLink processors from which we would benefit, so the complete implementation brings little extra value. Among the simplifications from Xlink are:</h:p>
        <h:ul>
          <h:li>
            <h:tt>type</h:tt>supports only
            <h:tt>extended</h:tt>,
            <h:tt>locator</h:tt>and
            <h:tt>arc</h:tt>
          </h:li>
          <h:li>
            <h:tt>label</h:tt>is not supported and
            <h:tt>id</h:tt>s are used as targets of links.</h:li>
          <h:li>
            <h:tt>show</h:tt>and
            <h:tt>actuate</h:tt>are not supported.</h:li>
          <h:li>
            <h:tt>xlink:title</h:tt>is not supported (all STM elements can have a
            <h:tt>title</h:tt>attribute).</h:li>
          <h:li>
            <h:tt>xlink:role</h:tt>supports any string (i.e. does not have to be a namespaced resource). This mechanism can, of course, still be used and we shall promote it where STM benefits from it</h:li>
          <h:li>The
            <h:tt>to</h:tt>and
            <h:tt>from</h:tt>attributes point to IDs rather than labels</h:li>
          <h:li>The xlink namespace is not used</h:li>
          <h:li>It is not intended to create independent linkbases, although some collections of links may have this property and stand outside the documents they link to</h:li>
        </h:ul>
      </h:div>
    </xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="anyCml"/>
      <xsd:any namespace="##other" processContents="lax"/>
      <xsd:any namespace="##local" processContents="lax"/>
    </xsd:choice>
    <xsd:attributeGroup ref="title"/>
    <xsd:attributeGroup ref="id"/>
    <xsd:attributeGroup ref="convention"/>
    <xsd:attributeGroup ref="dictRef"/>
    <xsd:attributeGroup ref="from"/>
    <xsd:attributeGroup ref="to"/>
    <xsd:attributeGroup ref="ref"/>
    <xsd:attributeGroup ref="fromType">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The type of the object/element in the 'from' attributes. Requires the objects referenced by the 'from' attributes to have a given elementType. Can be overridden by 'from' attributes in individual links. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="toType">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The type of the object/element in the 'to' attributes. Requires the objects referenced by the 'to' attributes to have a given elementType. Can be overridden by 'to' attributes in individual links. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="fromSet">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The set of ids in the base of the link. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="toSet">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The set of ids in the target of the link. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="fromContext">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The id of the ancestral element of objects referenced by 'from' attributes. Provides a context for uniquifying the references in the 'from' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'fromContext'. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="toContext">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The id of the ancestral element of objects referenced by 'to' attributes. Provides a context for uniquifying the references in the 'to' attributes. Thus atoms referenced by ids should be unique within a given molecule and the id of this could be the 'toContext'. 2005-06-18: created</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="role">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The role of the link. Xlink adds semantics through a URI; we shall not be this strict. We shall not normally use this mechanism and use dictionaries instead.</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="href">
      <xsd:annotation>
        <xsd:documentation>
          <h:div class="specific">The target of the (locator) link, outside the doc.</h:div>
        </xsd:documentation>
      </xsd:annotation>
    </xsd:attributeGroup>
    <xsd:attributeGroup ref="linkType"/>
    <xsd:anyAttribute namespace="##other" processContents="lax"/>
  </xsd:complexType>
</xsd:element>

Sample