1. STM has no name variants, and no parameters for name variations.
2. STM uses <name> instead of <baseName>, and <text> instead of <baseNameString>. (In the absence of the notion of variant names, the notion of base names is not very meaningful.)
3. STM does not use <xlink> to refer to pieces of information. Instead, it uses <a>, on the theory that more people are comfortable with <a href=""...> syntax than are comfortable with <xlink>.
4. STM has neither <subjectIndicatorRef> nor <resourceRef>. The vital distinction between subject indicators and subject constituters is preserved, however; the interpretation of the <a> elements, as to whether their referents are to be understood as subject constituters or subject indicators, is determined by the contexts of the <a> elements, as follows:
   • An <a> always references a subject indicator when it appears in the context of:
     • an <instanceOf>,
     • a <subjectIdentity>,
     • a <member>,
     • a <roleSpec>,
     • a <scope>, or
     • a <space>.
   • An <a> always references a subject constituter when it appears in the context of:
     • an <occurrence> or
     • a <mergeMap>.
5. STM has no <topicRef>. If an <a> refers to a <topic>, and the context of the <a> requires it to be understood as referencing a subject indicator, then the referent is the subject of the referenced <topic>. Otherwise, the <topic> is understood as a piece of information -- a subject constituter.
6. STM provides a <space> element, in addition to a <scope> element, for qualifying the relationships between named subjects and their names (see ).
7. STM does not provide as many element types with id attributes as XTM does. There are two explanations for this:
   1. It may be true that some of the id attributes provided by the XTM DTD were added in order to support "lazy" reification via references to the syntactic instance. However, in order to preserve the integrity of topic maps when they are merged with other topic maps, the TMM requires pre-emptive reification, so this requirement is considered moot.
   2. STM is not proposed as a full-featured syntax for Topic Maps. Instead, it is proposed as a lightweight, easily implementable alternative to XTM. As such, its SDD declares very few "topic demanders" (see the TMM for more information).
8. STM does not provide a <resourceData> element type. All occurrences must be external to STM topic maps.
9. STM requires that topics that have the same names in the same namespaces (declared via <space>) are always merged. (In other words, the name-based merging rule is always "on", but, on the other hand, in STM, namespacing and scoping are different things, whereas in XTM, they are the same.)
10. STM requires that <association>s declare at least two roles. This makes the deserialization of STM syntax considerably simpler than the deserialization of XTM syntax, since one-role <association>s in XTM syntax must be deserialized in a special way that creates a class-instance assertion.
11. STM requires all <association> roles to be explicitly invoked; this obviates the need for special defaulting rules in the Syntax Deserialization Definition, and/or special default assertion types and/or roles to be supplied by the governing TM Application.

  <!-- topicMap: root element -->
  <!ELEMENT topicMap ( topic | association | mergeMap )* >
  <!ATTLIST topicMap
     id              ID        #IMPLIED
     xmlns           CDATA     #FIXED 'http://www.isotopicmaps.org/TMMM/STM-%%VERSIONNUMBER%%/'
  >

  <!-- topic: referenceable syntactic surrogate of a subject -->
  <!ELEMENT topic 
     ( instanceOf*, subjectIdentity?, ( name | occurrence )* )
  >
  <!ATTLIST topic
     id              ID        #REQUIRED
  >

  <!-- instanceOf: points to a <topic> representing a class -->
  <!ELEMENT instanceOf  (a) >

  <!-- subjectIdentity: pointers to subject indicators -->
  <!ELEMENT subjectIdentity ( a* ) >

  <!-- a: wrapper for an -href- attribute -->
  <!ELEMENT a EMPTY >
  <!ATTLIST a
     href            CDATA     #REQUIRED
     id              ID        #IMPLIED
  >

  <!-- name: a name of the subject of the containing <topic> -->
  <!ELEMENT name  ( text, space?, scope?) >
            <!-- NOTE: The default topic name space is the empty
                       set (of topics). (Every topic-name
                       relationship exists within at least one
                       namespace.)  -->
            <!-- NOTE: The default scope in which topics have
                       their names is the empty set (of topics).
                       -->

  <!-- text: the name in #PCDATA form -->
  <!ELEMENT text ( #PCDATA ) >

  <!-- space: pointer to a <topic> or subject indicator whose
              subject is the name space within which the topic
              has the name -->
  <!ELEMENT space  (a) >

  <!-- scope: pointers to <topic>s or other indicators of
              subjects that comprise the scope -->
  <!ELEMENT scope  (a)+ >

  <!-- occurrence: relationship between a subject and relevant
                   information -->
  <!ELEMENT occurrence ( instanceOf?, scope?, a ) >
            <!-- NOTE: <instanceOf> points at an assertion type that
                       is either the topic-occurrence assertion type
                       (the default), or one of its subclasses. -->
            
  <!-- association: relationship between 2 or more subjects, each
                    playing one or more distinct roles -->
  <!ELEMENT association ( instanceOf, scope?, member, member+ ) >
  <!ATTLIST association
     id              ID        #IMPLIED
  >

  <!-- member: a casting of a role player in a role in a
               relationship -->
  <!ELEMENT member ( roleSpec, ( a )* ) >

  <!-- roleSpec: pointer to a topic whose subject is the role -->
  <!ELEMENT roleSpec  (a)

  <!-- mergeMap: Include (merge with) other topic maps -->
  <!ELEMENT mergeMap  ( a )+ >