[This local archive copy mirrored from the canonical site: http://www.hightext.com/tnm/psjan98.htm - January 22, 1998; links may not have complete integrity, so use the canonical document at this URL if possible.]
This international standard provides a general mechanism for assigning properties to information objects using links. Thus, an object described as having a given property need not possess the property intrinsically, but may have it assigned extrinsically using a topic navigation map. Because of the extrinsic character of a topic map, it may be thought of as an "overlay" on a set of information objects.
Note: The Greek word 'topos' from which the English word 'topic' originates means 'location'. Therefore, 'topic' means here the qualification of a subject by the locations in which it is mentioned.
Note: A parallel distinction between the intrinsic and the extrinsic exists in the world of book indexing: the subject headings of an index need not appear as strings in the indexed text; indeed, those headings that do not appear offer more potential value to the user than those that do appear, offering as they do a measure of abstraction.
An unlimited number of topic navigation maps may be overlaid on a given bounded object set. Thus, topic navigation maps enable multiple, concurrent views of information objects. These views may be relational, hierarchical, or both.
Note: Thus, topic navigation maps provide a flexible mechanism for defining database schemata.
Topic navigation maps may assign properties to information objects for the following applications, among others:
This standard provides for multilingual topic navigation maps. Filters may be set up to view or ignore information objects based on assigned properties including language or nationality. The topic navigation map's anchor roles (that is, its user interface) may be presented in a specific language using the localization attribute.
All property assignment in this standard is performed using
the HyTime varlink (variable link) architectural
form and any or all of the location addressing facilities of
HyTime. Therefore, information objects that can be addressed
through a Topic Navigation Map can exist in any notation.
Note: In its design, HyTime distinguishes rigorously between linking (a relation among information objects) and locating (addressing the information objects). This design decision is essential to topic map interchange.
This standard provides techniques, based on facilities defined in ISO/IEC 10744:1997, for assigning extrinsic properties to information objects using topics, and for linking sets of related topics.
Note: This standard does not require or disallow use of any addressing scheme for the location of information objects, or any format for document storage.
One field of application for the standard is the addition of information to data not intrinsically, as markup, but extrinsically, as an "overlay".
Note: Content created using embedded markup and overlays may be deemed to be equivalent.
This field of application includes, but is not limited to, the interchange of indexes, glossaries, cross-references, thesauri, and other such reference material.
If a document complies with all provisions of this International Standard, is a conforming SGML document as defined in ISO 8879, and is a conforming HyTime document as defined in ISO 10744:1997, it is a conforming Topic Navigation Map document.
Conformance to the Topic Navigation Map standard is independent of whether the document also conforms to any other document architecture.
A conforming Topic Map Engine must be able to perform architectural processing on the architectural forms defined in this standard: TNM::Topic, TNM::TopicRelationship, TNM::TopicTitle, TNM::Filter, and TNM::Anchspec.
Editor's note: The following paragraphs are imported from ISO 10744. They only need to be quoted here. To do: specify the way the TNM architecture is derived from the HyTime AFDR.
A.3.1 Enabling architectures
A document architecture can also be "enabling", in which case it does not specify complete document types. Instead, an enabling architecture defines rules, known as "architectural forms", that application designers can apply in their document type definitions. These rules, and the associated architectural semantics, are described in an "architecture definition document". The set of formal SGML specifications of the architectural forms, and related declarations for an enabling architecture, comprises a "meta-DTD".
Conceptually, there are two steps to architectural processing. In the first step, generic architectural processing, a generic architecture engine validates a client document against the meta-DTD of its base architectures and, optionally, creates an architectural instance for each base architecture. In the second step, an architecture-specific semantic engine processes both the relevant architectural instances and the client document in order to implement and/or validate architecture-specific semantics.
Note: In practice, these steps may be combined into a single architecture- or application-specific processor. In other words, an application-specific processor may implement architecture-defined semantics without doing generalized architectural processing.
Editor's note (SH): 1/2/98. so what is duplicative, if not identical to the original, should be removed?
Editor's note (SH): 1/2/98. Somewhere the "::" convention needs to be documented.
The terms and definitions given in ISO 8879:1986 and ISO/IEC 10744:1997 and the following terms and definitions apply to this standard.
For the purposes of this standard the conventions defined in Clause 5 of ISO/IEC 10744:1997 have been followed.
<!entity % loc -- Location address forms --
"anchloc|bibloc|dataloc|fcsloc|linkloc|listloc|
mixedloc|nameloc|nmsploc|pathloc|proploc|queryloc|
relloc|treeloc"
A topic navigation map may form a HyTime hub document. If this is the case, the base document element of the topic navigation map shall conform (except that the list of options provided in each parameter entity may be a subset of that shown) to the following architectural forms:
A Topic Map Engine shall be able to process the following subset of HyTime:
Editor's Note: To do: shrink this list
<!-- HyTime Topic Navigation Map Document Hub -->
<!entity %
loc -- Location address forms --
"anchloc|bibloc|dataloc|linkloc|listloc|mixedloc|nameloc|
nmsploc|pathloc|proploc|queryloc|relloc|treeloc" >
<!entity %
link -- Hyperlink forms --
"varlink" >
<!entity %
resbase -- Base module resource forms --
"bosspec" >
<!entity %
resloc -- Location address module resource forms --
"agrovdef|datatok|grovplan|pgrovdef" >
<!entity %
resschd -- Scheduling module resource forms --
"calspec|evsched|extent|extlist|measure" >
<!entity %
resorce -- All resource architectural forms --
"%resbase;|%resloc;|%resschd;" >
<!element TNM::hub -- Topic Navigation Map HyTime hub document element --
- O ANY +(%loc;|%link;|%resorce;)
-- OptionalAttributes [base]: bos, bosspcat --
-- OptionalAttributes [locs]: dgrvplan --
-- CommonAttributes [GenArc]: dvlatt, etfullnm, id, irefmodl,
ireftype, lextype --
-- CommonAttributes [base]: dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn -- >
<!attlist TNM::hub
TNM NAME #FIXED "TNM::hub"
HyTime NAME #FIXED "HyDoc" >
Note: The formal definition of the elements and attributes defined in this section is provided in Clause 6 of ISO/IEC 10744:1997.
<!entity % TNMCFC "ANY -(TNM::Topic | TNM::TopicRelationship | TNM::Anchspec | %locs;)"
Editor's note: Check if this notation is correct.
%TNMCFC; is the TNM equivalent of HyCFC. It includes PCDATA, Images, EMPTY, This is done in order to prevent titles and mnemonic to be separated from each other by indirections.
Language-dependent attribute names
Use valueref to allow the user to enter a single value for all three attributes.
Use #ALL to concentrate all cuteness in a single location.
<!-- Values for subdvl and sibdvl are taken from selfdvl --
<!-- and selfdvl renamed to Localization in AFDR --
<!attlist
#ALL
valueref CDATA #FIXED "subdvl selfdvl sibdvl selfdvl"
ArcNames CDATA "selfdvl localization"
The Topic Navigation Maps standard defines five architectural forms:
The TNM::Topic, TNM::TopicRelationship, and TNM::Filter
architectural forms are derived from the HyTime variable link (varlink)
architectural form. A variable link contains anchor specification
(anchspec) elements that define each anchor role.
Each anchspec contains the location elements that
address the members of that anchor.
A topic is a link that relates information objects with assigned properties in common for purposes of navigation.
Note: For example, in the subject heading index to a printed book, the term topic would encompass both the subject headings and the subject locators (page numbers, in all likelihood.)
A property assigned by a topic map is named by an anchor specification elements contained within the topic map element. Because a topic map may contain an unlimited number of anchor specification elements, it may assign an unlimited number of properties.
The topic element type form (TNM::Topic) may serve as the base architecture for as many link element types as desired in a DTD. Each such element becomes a topic element type. Different topic element types will typically have different sets of anchor specification elements (that is, assign different properties).
Most topic elements will be assigned a unique identifier (id) so that they can become part of a topic navigation map topic relationship (see Clause ???).
Note: Those topic elements that are intended to become part of a topic navigation map topic relationship must have a unique identifier (id). To prepare topic elements that can later play a role in a topic relationship, it is a good practice to assign ids to all topic elements, although this is not an absolute requirement of this standard.
<!element TNM::Topic
- -
(TopicTitle*, anchspec*)
<!attlist TNM::Topic
TNM
NAME TNM::Topic
HyTime
NAME
varlink
id
ID
#IMPLIED -- Constraint: id is required if topics
are to be anchors of topic relationships. --
linktrav -- Hyperlink traversal rules --
-- Traversal between anchors of hyperlinks: A
any traversal or departure (EID) --
(A|EI|ER|ED|EN|EP|ERD|I|ID|D|N|P|R|RD)
A
listtrav -- List traversal rules --
-- Traversal between members of list anchors:
A adjacent (both left and right) traversal
W wrapping traversal --
(A|AW|L|LW|N|R|RW)
AW -- Constraint: ignored if anchor is not a list --
>
The Topic Title architectural form is an anchor specification element (anchspec) containing the address of the element(s) by which a topic is known.
Note: As in SGML, the element pointed to by a topic title may be in any notation. Thus, a graphic or sound could become a topic title.
Note: The element containing the title may be inside or outside the topic map document.
Note: A topic may require multiple titles to create alternative entry points in a single language (for example, "Art Museum" and "Museum of Art"), or to provide titles in different languages.
A mnemonic attribute may be attached to the topic title anchor specification element, to allow a short name to be given to a title. Where no mnemonic is assigned, the contents of the title element will be used as the mnemonic. The way in which the value of the mnemonic attribute may be used is application-dependent.
Note: For example, values of the mnemonic attribute may be used to control the order in which topics that are entries in a subject index are to be sorted.
<!element TNM::TopicTitle
- -
(%loc;)>
<!attlist TNM::TopicTitle -- TNM::TopicTitle --
-- attributes used to identify titles associated
with Topic Navigation Map Topics --
-- Clause ???? --
TNM
NAME
"TNM::TopicTitle"
HyTime
NAME
"anchspec"
mnemonic -- The short name for the title text --
CDATA
#IMPLIED -- Default: Content of element --
anchrole -- Anchor role --
NAME
"TNM::TopicTitle"
-- Default: for anchspec, anchor role is GI of element --
-- Default: for varlink, varlink is not self anchor --
id
ID
#IMPLIED -- Id may be useful to apply filters on titles --
>
A topic is a link that relates topics with assigned properties in common for purposes of navigation.
Any number of relationships can exist between any two or more topics.
A property assigned by a topic relationship is named by an anchor specification elements contained within the topic relationship element. Because a topic relationship may contain an unlimited number of anchor specification elements, it may assign an unlimited number of properties.
The topic relationship element type form (TNM::TopicRelationship) may serve as the base architecture for as many link element types as desired in a DTD. Each such element becomes a topic relationship element type. Different topic element relationship types will typically have different sets of anchor specification elements (that is, assign different properties).
All other attributes in this architectural form have the same role as for the TNM::Topic element type architectural form (see Clause ????).
<!element TNM::Topicrelationship
- -
(anchspec,anchspec+)
<!attlist TNM::Topicrelationship
TNM
NAME
TNM::topicrelationship
HyTime
NAME
varlink
id
ID
#IMPLIED
linktrav -- Hyperlink traversal rules --
-- Traversal between anchors of hyperlinks:
A any traversal or departure (EID) --
(A|EI|ER|ED|EN|EP|ERD|I|ID|D|N|P|R|RD)
A
listtrav -- List traversal rules --
-- Traversal between members of list anchors:
A adjacent (both left and right) traversal
W wrapping traversal --
(A|AW|L|LW|N|R|RW)
AW -- Constraint: ignored if anchor is not a list --
A filter is a link that relates topics with assigned properties in common for purposes that are not navigational.
Note: For example, a language filter might be used to select (or ignore) anchors with an "English" property for subsequent viewing or traversal in a topic map.
Note: If a topic map can be thought of as an overlay, a filter can be thought of as a mask.
There are no constraints on the information objects that can be pointed to by filters. Filters can point to topics, to topic relationships, to anchor specification elements, to titles, etc.
The behavior of filters is left to the application designer. Topic Map Engines will be able to process the information pointed to by filter links by providing the necessary data that allow applications to build partial views, to extract portions or to provide selection mechanisms to users. Examples of filters include "Domain", "Language", "User profile", "Weighting", "Time-validity", "Security".
Note: Since the filter architectural form disables traversal, it is not possible to use the filter for navigation.
<!element TNM::Filter
- -
(anchspec)+
<!attlist TNM::Filter
TNM
NAME
TNM::Filter
HyTime
NAME
varlink
id
ID
#IMPLIED
linktrav -- Hyperlink traversal rules --
-- Traversal between anchors of hyperlinks:
N no traversal after internal arrival. --
(N) -- Filters are not for traversal. --
N
listtrav -- List traversal rules --
-- Traversal between members of list anchors:
N no traversal --
(N) -- Filters are not for traversal. --
N -- Constraint: ignored if anchor is not a list --
>
An anchor specification defines the anchor roles of, and contains the locators for, topic maps, topic relations, and filters. In a topic map, an anchor role names a property assigned to the information objects addressed by its locators.
Note: This standard places no restriction on location addressing methods. Located anchor addresses can be shared by different topics.
Editor's note. SH: Would it be more elegant to do this using a filter?
Editor's note. MBz: Yes, this would be clearer to explain (and probably easier to implement). To do: Study this possibility.
When a value for the "localization" attribute is not present, the generic identifier of the anchor specification names the assignable property (the anchor role) by default. Otherwise, the value must be the ID of an element conforming to the HyTime dvlist element form, which is a list of attribute specifications. These specifications are used to supply an assignable property name (the anchor role) to replace the default name. In this way, multilingual anchor roles are enabled.
Note: This is made possible by using the selfdvl, subdvl, and sibdvl (self-, subelement- and siblings default value list) architectural forms in HyTime. Subdvl and sibdvl take the same value as selfdvl (using the valueref attribute), and "selfdvl" is renamed "localization" (see 5.3).
The "multmem" attribute consolidates several anchors into one object by having the value "list". This value can be changed at the DTD level, if the application requires each anchor to be treated separately. However, if two anchspecs have the same generic identifier, none of them can have multmem=single.
<!element TNM::Anchspec
- O
(%loc;)*
<!attlist TNM::Anchspec -- Location address forms --
-- Reference --
-- Note: Use of refloc facility required --
HyTime
NAME
anchspec
anchrole
NAME
#IMPLIED -- Default: for anchspec, anchor role is GI of element --
localization -- Points directly to a specification for alternate
anchrole names --
IDREFS
#IMPLIED
multmem -- May anchor have multiple members? --
(single|list|corlist)
list
>
Typographic conventions used in the examples are:
This example declares that "Venice" is an instance of a topic belonging to the type "city".
This topic is a link that has two anchor roles: "title", and "description".
The title anchor points to an element called title, which is the title for the element. It contains the "name" of the topic, i.e. "Venice".
The description anchor points to two elements identified by the unique identifiers "id3" and "id4" which are located within a document whose entity name is "doc1", and to an element identified by the unique identifier "id5" located within a document whose entity name is "doc2".
Note: The following addressing markup is not optimized for saving space. Many alternatives are possible. It shows the syntax of addressing aggregates in multiple documents using HyTime 1997 architectural forms.
Note that this international standard provides a common representation for linking semantics. The syntax of addressing is left to the application. The DTD used to represent the topic map information is application-specific, and is only given here as an example. What matters for ISO 13250 conformance is the use of TNM architectural forms, but not the DTD itself.
<Topicmap>
<TopicTitle id=id1>Venice</TopicTitle>
<City id=Ven>
<TitleAnchor mnemonic=Venice id=tit1>
<mixedloc>
<nmsploc>id1</nmsploc>
</mixedloc>
</TitleAnchor>
<DescriptionAnchor>
<mixedloc>
<nmsploc locsrc=doc1>id3 id4</nmsploc>
<nmsploc locsrc=doc2>id5</nmsploc>
</mixedloc>
</DescriptionAnchor>
</City>
</Topicmap>
<!DOCTYPE TopicMap [ <!ELEMENT TopicMap - - ( (TopicTitle*, City) | (TopicTitle*, Country) )+ > <!-- Topic Titles --> <!ELEMENT TopicTitle - - (#PCDATA) > <!ATTLIST TopicTitle id ID #REQUIRED > <!-- Topics --> <!ELEMENT City - - (TitleAnchor,DescriptionAnchor?) > <!ATTLIST City tnm NAME TNM::Topic HyTime NAME varlink id ID #IMPLIED > <!ELEMENT Country - - (TitleAnchor,MentionAnchor?, HistoryAnchor?) > <!ATTLIST Country tnm NAME TNM::Topic HyTime NAME varlink id ID #IMPLIED > <!-- Anchors --> <!ELEMENT TitleAnchor - - (mixedloc) > <!ATTLIST TitleAnchor tnm NAME TNM::TopicTitle #FIXED mnemonic CDATA #IMPLIED id ID #IMPLIED HyTime NAME anchspec > <!ELEMENT DescriptionAnchor - - (mixedloc) > <!ATTLIST DescriptionAnchor tnm NAME TNM::Anchspec HyTime NAME anchspec anchrole NAME Description > <!ELEMENT MentionAnchor - - (mixedloc) > <!ATTLIST MentionAnchor tnm NAME TNM::Anchspec HyTime NAME anchspec anchrole NAME Mention > <!ELEMENT HistoryAnchor - - (mixedloc) > <!ATTLIST HistoryAnchor tnm NAME TNM::Anchspec HyTime NAME anchspec anchrole NAME History > <!-- Addresses --> <!ELEMENT mixedloc - - (nmsploc)+ > <!ATTLIST mixedloc HyTime NAME mixedloc > <!ELEMENT nmsploc - - (#PCDATA) > <!ATTLIST nmsploc HyTime NAME nmsploc locsrc CDATA #IMPLIED > ]>
This example uses the TEI Xpointers syntax to address elements in external documents.
<TopicMap>
<TopicTitle id=id1>Venice</TopicTitle>
<City id=Ven>
<TitleAnchor mnemonic=Venice id=tit1>
<ptr target=id1>
</TitleAnchor>
<DescriptionAnchor>
<xptr doc=doc1 from='id (id3)'>
<xptr doc=doc1 from='id (id4)'>
<xptr doc=doc2 from='id (id5)'>
</DescriptionAnchor>
</City>
</TopicMap>
<!DOCTYPE TopicMap [
<!ELEMENT TopicMap - - ( (TopicTitle*, City) | (TopicTitle*, Country) )+ >
<!ELEMENT TopicTitle - - (#PCDATA) >
<!ATTLIST TopicTitle
id ID #REQUIRED
>
<!ELEMENT City - - (TitleAnchor, DescriptionAnchor?) >
<!ATTLIST City
tnm NAME TNM::Topic
HyTime NAME varlink
id ID #IMPLIED
>
<!ELEMENT Country - - (TitleAnchor, MentionAnchor?, History?) >
<!ATTLIST Country
tnm NAME TNM::Topic
HyTime NAME varlink
id ID #IMPLIED
>
<!-- Anchors -->
<!ELEMENT TitleAnchor - - (ptr)+ >
<!ATTLIST TitleAnchor
tnm NAME TNM::TopicTitle
HyTime NAME anchspec
mnemonic CDATA #IMPLIED
>
<!ELEMENT DescriptionAnchor - - (xptr)+ >
<!ATTLIST DescriptionAnchor
tnm NAME TNM::Anchspec
HyTime NAME anchspec
>
<!ELEMENT MentionAnchor - - (xptr) >
<!ATTLIST MentionAnchor
tnm NAME TNM::Anchspec
HyTime NAME anchspec
>
<!ELEMENT HistoryAnchor - - (xptr) >
<!ATTLIST HistoryAnchor
tnm NAME TNM::Anchspec
HyTime NAME anchspec
>
<!-- TEI DTD -->
<!-- ptr (pointer) used for titles, required here to be in the
topic map document -->
<!-- xptr (extended pointer) used for addressing anchors in
external documents -->
<!ELEMENT ptr - O EMPTY>
<!ATTLIST ptr
ana IDREFS #IMPLIED
corresp IDREFS #IMPLIED
next IDREF #IMPLIED
prev IDREF #IMPLIED
id ID #IMPLIED
n CDATA #IMPLIED
lang IDREF #IMPLIED
rend CDATA #IMPLIED
type CDATA #IMPLIED
resp CDATA #IMPLIED
crdate CDATA #IMPLIED
targType NAMES #IMPLIED
targOrder (Y | N | U) "U"
evaluate (all | one | none) #IMPLIED
target IDREFS #REQUIRED
TEIform CDATA "ptr" >
<!ELEMENT xptr - O EMPTY>
<!ATTLIST xptr
ana IDREFS #IMPLIED
corresp IDREFS #IMPLIED
next IDREF #IMPLIED
prev IDREF #IMPLIED
id ID #IMPLIED
n CDATA #IMPLIED
lang IDREF #IMPLIED
rend CDATA #IMPLIED
type CDATA #IMPLIED
resp CDATA #IMPLIED
crdate CDATA #IMPLIED
targType NAMES #IMPLIED
targOrder (Y | N | U) "U"
evaluate (all | one | none) #IMPLIED
doc ENTITY #IMPLIED
from CDATA "ROOT"
to CDATA "DITTO"
TEIform CDATA "xptr"
>
]>
Note: The examples 1 and 2 are identical for the semantic properties applied to the topic, but they use a different addressing mechanism. The two topic map documents are interchangeable from the perspective of ISO 13250. Interchange may become operational if a mapping mechanism exists between the two forms of addressing. It is outside the scope of this international standard to provide mechanisms for address interchangeability, especially because there are a number of topic map applications which address information stored in proprietary formats. However, interchange is greatly facilitated by the fact that linking semantics is kept separate from addressing semantics.
In this example, the topic "Venice" has two titles: "Venice" and "Venezia".
<TopicTitle id=id1>Venice</TopicTitle>
<TopicTitle id=id2>Venezia</TopicTitle>
<City id=Ven>
<TitleAnchor mnemonic=Venice id=tit1><nmsploc>id1</nmsploc></TitleAnchor>
<TitleAnchor mnemonic=Venezia id=tit2><nmsploc>id2</nmsploc></TitleAnchor>
<DescriptionAnchor>
<mixedloc>
<nmsploc locsrc=doc1>id3 id4</nmsploc>
<nmsploc locsrc=doc2>id5</nmsploc>
</mixedloc>
</DescriptionAnchor>
</city>
Editor's note : In this example and the following, insert DTDs.
This example extends the example 3.1 to three topic declarations.
In this example, the optional attribute mnemonic is not present.
Note that Venice has occurrences (descriptions) in some documents, while "Rome" and "Italy" have no occurrences. They are still fully valid topics.
<TopicTitle id=id1>Venice</TopicTitle>
<TopicTitle id=id2>Venezia</TopicTitle>
<City id=Ven>
<TitleAnchor id=tit1><nmsploc>id1</nmsploc></TopicTitle>
<TitleAnchor id=tit2><nmsploc>id2</nmsploc></TopicTitle>
<DescriptionAnchor>
<mixedloc>
<nmsploc locsrc=doc1>id3 id4</nmsploc>
<nmsploc locsrc=doc2>id5</nmsploc>
</mixedloc>
</DescriptionAnchor>
</City>
<TopicTitle id=id6>Rome</TopicTitle> <TopicTitle id=id7>Roma</TopicTitle> <City id=Rom> <TitleAnchor id=tit6><nmsploc>id6</nmsploc></TitleAnchor> <TitleAnchor id=tit7><nmsploc>id7</nmsploc></TitleAnchor> </City>
<TopicTitle id=id8>Italy</TopicTitle> <TopicTitle id=id9>Italia</TopicTitle> <Country id=It> <TitleAnchor id=tit8><nmsploc>id8</nmsploc></TitleAnchor> <TitleAnchor id=tit9><nmsploc>id9</nmsploc></TitleAnchor> </Country>
This examples expresses the fact that Rome and Venice are both in Italy.
In TNM terms, it translates as: The topic "Italy" is related to the topics "Rome" and "Venice" through a topic relationship whose semantics is "containment".
<Containment> <Container><nmsploc>It</nmsploc></Container> <Contained><nmsploc>Rom Ven</nmsploc></Contained> </Containment>
Note: If the DTD does not allow aggregates into topic relationships anchroles, i.e. is limited to one-to-one relationships, the same example could be written instead: Italy contains Venice and Italy contains Rome:
<Containment> <Container><nmsploc>It</nmsploc></Container> <Contained><nmsploc>Ven</nmsploc></Contained> </Containment> <Containment> <Container><nmsploc>It</nmsploc></Container> <Contained><nmsploc>Rom</nmsploc></Contained> </Containment>
In the example 3.2, topics have alternate titles. These titles (whose anchor specs are identified by tit1 and tit2) happen to be in different languages. Furthermore, if the element (e.g. a section) which is identified by id3 in doc2 is in English, while the element identified by id4 in doc2 is in Italian, it is possible to describe these properties using a TNM::filter hyperlink for language. Note that hyperlinks enable pointing to elements belonging to various types.
<Language> <English> <mixedloc> <nmsploc>tit1 tit6 tit8</nmsploc> <nmsploc locsrc=doc1><nmsploc>id3</nmsploc> </mixedloc> </English> <Italian> <mixedloc> <nmsploc>tit2 tit7 tit9</nmsploc> <nmsploc locsrc=doc2><nmsploc>id4 id5</nmsploc> </mixedloc> </Italian> </Language>
The architectural form definitions defined in Annex A shall be associated with each SGML document type definition that conforms to this standard.
Note: Normally this will be done by using a parameter reference to point to a file containing a copy of the declarations given in Annex A.
The architectural form definition for topic navigation maps references the architectural form definitions for HyTime. The architectural forms in this standard are identified as being applicable to element type forms defined in the HyTime standard. The attributes defined in the topic navigation map architectural forms extend the set defined for the referenced architectural forms in ISO/IEC 10744:1997, which must also be applied as appropriate for the element types used to define a topic map.
This annex formally defines the enabling architectures required to implement topic navigation maps. It is defined using the specification for Architectural Form Definition Requirements in the SGML Extended Facilities annex of ISO/IEC 10744:1997. The meta-DTD defined by this document starts, therefore, with a (non-processable) markup declaration of the form:
<!AFDR "ISO/IEC 10744:1997">
The SGML declaration accompanying a document containing a
topic navigation map shall include the token ArcBase
in its APPINFO field to indicate that details of the
SGML architectures for which support is required will be found in
processing instructions starting with the (default) ArcBase
keyword. If another name is required to identify applicable
processing instructions it can be specified, as part of the same
token, by using the form ArcBase=ArcUsed.
An SGML document type definition (DTD) that uses the
facilities defined in this standard shall contain, as near to the
start of the part of the DTD that contains definitions using
HyTime or the architectural forms defined in this document as
possible, a processing instruction, coded using the document's
concrete syntax, whose contents are IS10744 ArcBase TNM
HyTime where IS10744 indicates that this
standard conforms the the Architectural Form Definition
Requirements specified in Annex A of ISO/IEC 10744:1997, ArcBase
is the name assigned for identifying architectural bases in the APPINFO
section of the SGML declaration associated with the DTD, TNM
is a mnemonic used throughout this standard to identify
components of a Topic Navigation Map and HyTime is
the name of the base architecture from which topic navigation
maps are derived.
A DTD that uses the facilities defined in this standard shall contain an SGML notation declaration and architectural support attribute definitions based on the template shown below, modified if necessary to conform to the concrete syntax defined in the associated SGML declaration:
<!NOTATION TNM PUBLIC "ISO 13250:1998//NOTATION AFDR ARCBASE
Topic Navigation Map
Architecture Definition Document//EN"
-- A derived architecture used in conformance with the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. -->
<!ATTLIST #NOTATION TNM
ArcFormA NAME #FIXED "TNM"
ArcNamrA NAME TNM::name
-- Can be used to assign locally
meaningful names to TNM attributes --
ArcDTD CDATA #FIXED "TNM::DTD"
ArcDocF NAME "TNM::hub"
ArcAuto (ArcAuto|nArcAuto) "nArcAuto"
ArcQuant CDATA #FIXED "NAMELEN 24"
-- NAMELEN has been extended to 24 to allow "natural" naming
to be applied to Topic Navigation Map attribute values -- >
Editor's Question: Do we need other attributes here, such as ArcBridF and ArcSuprA (or is the fact that the standard HyTime options are defined in the next section sufficient)? Sam: We don't need ArcBridF because we are doing an overlay. So where's the bridge? What's to suppress? No ArcSuprA either.
Note: Definitions of the attributes defined in this declaration are provided in Annex A of the 2nd Edition of ISO/IEC 10744.
Editor's note (Michel + Sam): We should try to keep this section as small as we can.
The DTD must also contain the following entity definition, with its associated notation declaration, which is referenced by the following architecture support attributes:
<!NOTATION AFDRMeta --AFDR Meta-DTD Notation--
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR
Meta-DTD Notation//EN" >
<!ENTITY TNM::DTD -- Meta-DTD for navigation map instances --
PUBLIC "ISO 13250:1998//DTD AFDR Meta-DTD
Topic Navigation Map//EN" CDATA AFDRMeta >
In addition support should be declared for at least a minimal set of HyTime functionality by including the following declarations:
<!-- HyTime Support Declarations -->
<!NOTATION
HyTime -- HyTime Architecture --
-- A base architecture used in conformance with the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. --
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR ARCBASE
Hypermedia/Time-based Structuring Language (HyTime)//EN"
>
<!ATTLIST #NOTATION HyTime
ArcFormA NAME HyTime
ArcNamrA NAME HyNames
ArcSuprA NAME sHyTime
ArcIgnDA NAME HyIgnD
ArcDocF NAME HyDoc
ArcDTD CDATA "HyTime"
ArcQuant CDATA #FIXED "NAMELEN 9"
-- NAMELEN must be at least 9 because the HyTime meta-DTD uses
8-character parameter entity names. --
ArcDataF NAME #FIXED HyBridN
ArcBridF NAME #FIXED HyBrid
ArcAuto (ArcAuto|nArcAuto) nArcAuto
ArcOptSA NAMES "GenArc base locs links"
GenArc -- General architecture facilities --
CDATA -- Lextype: csname+ --
"HyLex ireftype lextype"
base -- Base module facilities --
CDATA -- Lextype: csname+ --
"bos bosspec conloc dimspec HyDimLst HyDimSpc valueref"
locs -- Location address module facilities --
-- Clause: 6.3 --
CDATA -- Lextype: csname+ --
"agrovdef bibloc dataloc datatok grovplan listloc mixedloc
multloc nameloc nmsploc pathloc pgrovdef proploc queryloc
refctl referatt refloc reftype relloc spanloc treecom treeloc
treetype"
links -- Hyperlinks module facilities --
-- Clause: 6.3 --
CDATA -- Lextype: csname+ --
"agglink anchloc clink hylink ilink linkloc traverse varlink"
sched -- Scheduling module facilities --
-- Clause: 6.3 --
CDATA -- Lextype: csname+ --
"calspec dimref grpdex grprepet HyCalSpc HyExSpec
HyExtLst HyGrand measure objalign pulsemap sched"
anysgml -- Any SGML declaration allowed --
-- Clause: 6.3 --
(anysgml|nanysgml) anysgml
exrefs -- External references allowed --
-- Clause: 6.3 --
(exrefs|nexrefs) exrefs
refmodel -- SGML model groups for reftype --
-- Clause: 6.3 --
(SGMLmdl|nSGMLmdl) SGMLmdl
hyqcnt -- Highest quantum count limit --
-- Clause: 6.3 --
NUMBER -- Constraint: power of 2 >= 32 --
32
manyanch -- Maximum number of anchors allowed in
hyperlinks --
-- Clause: 6.3 --
NUMBER -- Constraint: must be >= 2 --
#IMPLIED -- Default: no limit --
>
<!NOTATION AFDRMeta
PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR Meta-DTD Notation//EN"
>
<!ENTITY
HyTime -- HyTime meta-DTD --
-- Clause: 6.3 --
PUBLIC "ISO/IEC 10744:1997//DTD AFDR Meta-DTD
Hypermedia/Time-based Structuring Language (HyTime)//EN"
CDATA AFDRMeta
>
All of the addressing mechanisms allowed by HyTime may be used in the context of this standard. However, each application can limit itself to a more specific list of the options relevant to its context by removing unused options from the declarations given above.
This annex brings together all of the formal productions of this standard in a form that creates a valid SGML meta-DTD for topic naviation navigation maps.
Note: While the copyright of this standard rests with ISO, the formal SGML definitions provided in this Annex may be copied providing that the following text is included, for example as an SGML comment, with the copy:
(C) International Organization for Standarization 1998. Permission to copy in any form is granted for use with conforming Topic Navigation Maps as defined in ISO 13250, providing that this notice is included with all copies.
The meta-DTD constructs required for Topic Navigation Map processing are:
Editor's note: To be added later.