[Cache from http://www.y12.doe.gov/sgml/sc34/document/0328.htm, copied 2003-02-07. Use the canonical version if possible.]
ISO/IEC JTC 1/SC34 N0328
Title: | The XML Topic Maps (XTM) Syntax |
Source: | Lars Marius Garshol, Graham Moore, JTC1/SC34 |
Project: | ISO 13250 |
Project editor: | Steven R. Newcomb, Michel Biezunski, Martin Bryan |
Status: | Editor's draft |
Action: | For review and comment |
Date: | 2002-07-22 |
Summary: | |
Distribution: | SC34 and Liaisons |
Refer to: | |
Supercedes: | |
Reply to: | Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Information Technology Services Bldg. 9113 M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 E-mailk: mailto:mxm@y12.doe.gov http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 25 West 43rd Street New York, NY 10036 Tel: +1 212 642-4937 Fax: +1 212 840-2298 E-mail: shafele@ansi.org |
This specification defines the XML Topic Maps 1.0 (XTM) interchange syntax for topic maps, a syntax based on XML, XLink, and URIs. The allowed syntactical expressions in XTM documents are constrained using a DTD and prose, and their interpretation is defined using [SAM]. Note that this is only a syntax specification; what the syntax represents is defined by [SAM].
This specification will replace [XTM1.0] as the official definition of the XTM syntax once it is adopted by ISO as part of the revised ISO 13250 standard. For more information on this process, see [tm-guide].
This is $Revision: 1.11 $.
1 Introduction
2 Syntax
2.1 The
topicMap element
2.2 The topic
element
2.3 The subjectIdentity
element
2.4 The baseName
element
2.5 The baseNameString
element
2.6 The variant
element
2.7 The variantName
element
2.8 The parameters
element
2.9 The scope
element
2.10 The instanceOf
element
2.11 The occurrence
element
2.12 The resourceData
element
2.13 The association
element
2.14 The member
element
2.15 The roleSpec
element
2.16 The topicRef
element
2.17 The
subjectIndicatorRef element
2.18 The resourceRef element
2.19
The mergeMap element
3 Deserialization
3.1
Common processing
rules
3.1.1
Computing the URI of an
element
3.1.2
Computing absolute
URIs
3.1.3
Creation of new information
items
3.2 The topicMap
element
3.3 The topic
element
3.4 The subjectIdentity
element
3.5 The baseName
element
3.6 The baseNameString
element
3.7 The
variant element
3.8
The variantName
element
3.9 The
parameters element
3.10
The scope
element
3.11 The
instanceOf element
3.12 The
occurrence element
3.13 The
association element
3.14 The
member element
3.15
The topicRef
element
3.16
The subjectIndicatorRef
element
3.17 The resourceRef
element
3.18 The
mergeMap element
4 Conformance
A References
B The XTM 1.0 DTD
C Serialization
(Non-Normative)
XTM 1.0 is a syntax for the interchange of topic map information. The syntax is not designed to be extended or modified, although topic maps expressed in XTM may be embedded in other XML syntaxes. Other XML syntaxes that represent topic map information may well define mappings to the XTM syntax, however.
An XTM topic map is a topic map
serialized in XTM syntax as a topicMap
element with descendants. An XTM
document is an XML document that contains one or more XTM topic maps.
In a process known as deserialization, the XTM topic map is read by a topic map
processor, which produces from it some representation of the Standard
Application Model, by following a procedure equivalent to the one defined in
this specification.
The deserialization procedure is defined as a transformation that takes an element item from an XML Information Set [infoset] as input and produces a Standard Application Model instance as output. This specification does not concern itself with the means by which the XML Information Set used as input is produced. In most cases it will be produced by parsing an XML document, but other possibilities are specifically allowed, including architectural processing or XSLT transformation from other XML syntaxes.
This specification also provides informative guidance on how to serialize instances of the Standard Application Model to the XTM syntax.
Does XTM allow full XPointer references, or only bare names?
Is whitespace allowed in the xlink:href
attribute? If it is allowed, how is it interpreted? If it is not
allowed, what action is taken when it is found?
This section defines the XTM syntax, using prose and a DTD. The full DTD can be found in B The XTM 1.0 DTD.
topicMap
element The topicMap
element is the root element of all XTM topic maps. It acts as a
container for the topic map, and can be either the document element of an XML
document, or it may be the root of a subtree inside an XML document that
contains more than just a single topic map. In both cases, the input to the XTM
deserialization process is the subtree contained by the topicMap
element.
The topicMap
element type is declared as follows:
<!ELEMENT topicMap ( topic | association | mergeMap )* > <!ATTLIST topicMap id ID #IMPLIED xmlns CDATA #FIXED 'http://www.topicmaps.org/xtm/1.0/' xmlns:xlink CDATA #FIXED 'http://www.w3.org/1999/xlink' xml:base CDATA #IMPLIED > |
The attributes have the following meanings:
id
A unique identifier for the topic map within the document. Used to refer to the topic map.
xml:base
An attribute used to override the base URI of the document
inside the topicMap
element, as specified in [XMLBase].
xmlns
This attribute declares the default namespace to be used throughout the XTM document.
Attributes declared as #FIXED in the DTD can not be guaranteed to always be present in the XML document as parsed, either because there is no DOCTYPE declaration, or because the parser does not read the DTD. This affects both namespace and XLink parsing, which again affects procedure used to recognize element types.
xmlns:xlink
This attribute declares the xlink
namespace prefix to be used throughout the XTM document.
topic
element The topic
element type is used to create topics, and acts as a container and
point of reference for topic information. The child elements of the topic
element provide some topic characteristic assignments, as well as other
properties, while association roles played by the topic are specified outside
the topic
element.
The topic
element type is declared as follows:
<!ELEMENT topic ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* ) > <!ATTLIST topic id ID #REQUIRED > |
The id
attribute provides a unique identifier for the topic, which is used to
refer to it.
subjectIdentity
element The subjectIdentity
element type is used to formally declare the subject of the topic
created by the parent element, through its child elements.
The subjectIdentity
element type is declared as follows:
<!ELEMENT subjectIdentity ( resourceRef?, (topicRef | subjectIndicatorRef)* ) > <!ATTLIST subjectIdentity id ID #REQUIRED > |
The id
attribute is ignored during deserialization.
baseName
element The baseName
element type is used to add base names to the topic created by the
parent topic
element. The child elements of the baseName
element provide the property values of the base name item.
The baseName
element type is declared as follows:
<!ELEMENT baseName ( scope?, baseNameString, variant* ) > <!ATTLIST baseName id ID #IMPLIED > |
The id
attribute provides a unique identifier for the base name, which can be
used to refer to it.
baseNameString
element The baseNameString
element type is used to provide the string that makes up a base name.
The baseNameString
element type is declared as follows:
<!ELEMENT baseNameString ( #PCDATA ) > <!ATTLIST baseNameString id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
variant
element The variant
element type is used to create a variant name of a base name, and may
also contain other variant names with scopes that are supersets of the scope of
that of the containing variant name.
The variant
element type is declared as follows:
<!ELEMENT variant ( parameters, variantName?, variant* ) > <!ATTLIST variant id ID #IMPLIED > |
The id
attribute provides a unique identifier for the variant name, which is
used to refer to it.
variantName
element The variantName
element type is used to contain the element that specifies the
information resource that is the actual variant name.
The variantName
element type is declared as follows:
<!ELEMENT variantName ( resourceRef | resourceData ) > <!ATTLIST variantName id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
parameters
element The parameters
element type is used to specify the scope of a variant name, in
addition to the scope it inherits from its parent base name or variant name.
The parameters
element type is declared as follows:
<!ELEMENT parameters ( topicRef | subjectIndicatorRef )+ > <!ATTLIST parameters id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
scope
element The scope
element type is used throughout XTM to indicate the scope of a topic
characteristic assignment.
The scope
element type is declared as follows:
<!ELEMENT scope ( topicRef | resourceRef | subjectIndicatorRef )+ > <!ATTLIST scope id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
instanceOf
element The instanceOf
element type is used throughout XTM to indicate the type of the
construct represented by its parent element. The type is always a topic,
indicated by the child element.
The instanceOf
element type is declared as follows:
<!ELEMENT instanceOf ( topicRef | subjectIndicatorRef ) > <!ATTLIST instanceOf id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
occurrence
element The occurrence
element type is used to assign an occurrence to a the topic created by
the parent element.
The occurrence
element type is declared as follows:
<!ELEMENT occurrence ( instanceOf?, scope?, ( resourceRef | resourceData ) ) > <!ATTLIST occurrence id ID #IMPLIED > |
The id
attribute is used to refer to the occurrence.
resourceData
element The resourceData
element type is used to provide an information resource in the form of
a string contained within the XTM document. This information resource may be
either a variant name or an occurrence.
The resourceData
element type is declared as follows:
<!ELEMENT resourceData ( #PCDATA ) > <!ATTLIST resourceData id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
association
element The association
element type is used to express associations between topics. The member
child elements provide the association role players of the association.
The association
element type is declared as follows:
<!ELEMENT association ( instanceOf?, scope?, member+ ) > <!ATTLIST association id ID #IMPLIED > |
The id
attribute is used to refer to the association.
member
element The member
element type is used to add one or more players of the same association
role type to the association created by the association
parent element.
The member
element type is declared as follows:
<!ELEMENT member ( roleSpec?, ( topicRef | resourceRef | subjectIndictorRef )* ) > <!ATTLIST member id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
roleSpec
element The roleSpec
element type is used to specify the association role type played by the
association player contained in the member
parent element.
The roleSpec
element type is declared as follows:
<!ELEMENT roleSpec ( topicRef | subjectIndicatorRef ) > <!ATTLIST roleSpec id ID #IMPLIED > |
The id
attribute is ignored during deserialization.
topicRef
element The topicRef
element type is used throughout XTM to refer to a topic, either within
the same XML document or externally. The signficance of the reference depends
on the context.
The topicRef
element type is declared as follows:
<!ELEMENT topicRef EMPTY> <!ATTLIST topicRef id ID #IMPLIED xlink:href CDATA #REQUIRED > |
The attributes have the following meanings:
id
This attribute is ignored during deserialization.
xlink:href
Contains the URI that is the topic reference.
Is it an error for a topicRef
element to refer to a non-existing topic?
Issue (xtm-topicref-notatopic):
Is it an error for a topicRef
element to refer to an element that is not a topic
element?
Issue (xtm-topicref-fragment):
Is the URI given in the xlink:href
attribute (of topicRef
elements) required to have a fragment identifier?
subjectIndicatorRef
element The subjectIndicatorRef
element type is used throughout XTM to refer to a subject indicator.
The signficance of the reference depends on the context.
The subjectIndicatorRef
element type is declared as follows:
<!ELEMENT subjectIndicatorRef EMPTY> <!ATTLIST subjectIndicatorRef id ID #IMPLIED xlink:href CDATA #REQUIRED > |
The attributes have the following meanings:
id
This attribute is ignored during deserialization.
xlink:href
Contains the URI of the subject indicator being referred to.
resourceRef
element The resourceRef
element type is used throughout XTM to refer to an information
resource. The signficance of the reference depends on the context.
The resourceRef
element type is declared as follows:
<!ELEMENT resourceRef EMPTY> <!ATTLIST resourceRef id ID #IMPLIED xlink:href CDATA #REQUIRED > |
The attributes have the following meanings:
id
This attribute is ignored during deserialization.
xlink:href
Contains the URI of the information resource being referred to.
mergeMap
element The mergeMap
element type is used throughout XTM to refer to external topic maps
that are to be merged into the topic map that contains the mergeMap
element. The child elements of the mergeMap
element specify topics to be added to the scopes of all topic
characteristic assignments in the topic map to be merged in.
The mergeMap
element type is declared as follows:
<!ELEMENT mergeMap ( topicRef | resourceRef | subjectIndicatorRef )* > <!ATTLIST mergeMap id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED > |
The attributes have the following meanings:
id
This attribute is ignored during deserialization.
xlink:type
This attribute declares the mergeMap
element to be a simple XLink element.
xlink:href
This attribute contains the URI that refers to the topic map
to be merged into the current topic map. It must refer either to a topicMap
element, or to an XTM document.
Issue (xtm-mergemap-reference):
Is it an error if a mergeMap
element refers to an XML document that contains multiple topicMap
elements without providing a disambiguating fragment reference?
This section defines deserialization of instances of the XTM syntax into the Standard Application Model.
The input to the deserialization process is an element information
item in the XML Information Set and all its descendant nodes. In most cases
this will be the document element, but in cases where the topicMap
element is embedded in other XML syntaxes applications may select one
element item and use it as the input to the deserialization process. The means
by which this element item is chosen are beyond the scope of this
specification.
Deserialization is done by processing each element item in the input subtree of the XML Information Set in document order. For each element item encountered the operations specified in the subsection labelled "Processing" inside the section about that element type are performed.
An input element item matches a section in this document when the
[namespace name] property is set to "http://www.topicmaps.org/xtm/1.0/"
, and the [local name] matches the element type name given in that
section. Elements that do not match any section are ignored.
Issue (xtm-namespace-support):
The text as specified here requires that XTM processors do XML Namespace processing. Is that acceptable? XTM 1.0 seems to imply that namespace processing is optional. Also, proper namespace processing allows the use of different namespace prefixes, which break straight DTD validation.
Unknown elements are ignored in order to ensure forwards compatibility, but this means DTD compliance cannot be required. Which is more important?
This section defines common processing rules used throughout this specification. These rules are referenced from the sections they apply to.
The URI of an element is computed by first concatenating the "#"
character and the value of the [normalized value] property of the
attribute item in the [attributes] property of that element item whose [local
name] property is set to "id"
. This yields a relative URI that is then resolved to an absolute URI by
using the URI found in the [base URI] property of the element item as the base
URI.
RFC 2396, section 4.2, specifies that URI references of the form "" and "#fragment" are resolved relative to the URI of the current entity. Should XTM should follow this?
URI references found in attribute values in the input XML Information Set are absolutized by resolving them against the URI found in the [base URI] property of the element item found in the [owner element] property of the attribute item.
Ed. Note:
Dependency on the xtm-same-doc-refs issue here.
topicMap
element The topicMap
element causes a topic map item to be created.
If the topicMap
element has an id
attribute a locator item is created, with the [notation] property set
to "URI"
and the [address] property set to the URI of the topicMap
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the topic map item.
If the topicMap
element has an xml:base
attribute this does not affect the Standard Application Model instance
being built, except insofar as it modifies the input XML Information Set.
topic
element The topic
element causes a topic item to be created and inserted into the
[topics] property of the topic map item.
The id
attribute causes a locator item to be created, with the [notation]
property set to "URI"
and the [address] property set to the URI of the topic
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the topic item.
subjectIdentity
element The subjectIdentity
element has no direct effect on the information set, but changes the
interpretation of the child elements. The child elements are processed as
follows:
If there is a resourceRef
child, a locator item is produced with the [notation] property set to "URI"
, and the [address] property set to the absolute form of the URI in the
element's xlink:href
attribute. The locator item is set as the value of the [subject
address] property of the topic item created by the parent topic
element. The absolute URI is produced according to the procedure
described in 3.1.2 Computing absolute
URIs.
For every subjectIndicatorRef
child, a locator item is produced with the [notation] property set to "URI"
, and the [address] property set to the absolute form of the URI in the
element's xlink:href
attribute. The locator item is set as the value of the [subject
identifiers] property of the topic item created by the parent topic
element. The absolute URI is produced according to the procedure
described in 3.1.2 Computing absolute
URIs.
For every topicRef
child a topic item is produced according to the rules of
3.15 The topicRef element. That topic
item is then merged with the topic item created from the parent topic
element according to the rules of
the
Standard Application Model, 4.1 Merging topics.
If the subjectIdentity
element has an id
attribute that attribute is ignored.
baseName
element The baseName
element causes a base name item to be created, and added to the [base
names] property of the topic item created by the parent topic
element.
If the baseName
element has an id
attribute a locator item is created, with the [notation] property set
to "URI"
and the [address] property set to the URI of the baseName
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the base name item.
baseNameString
element The information items in the [children] property of the baseNameString
element are traversed, and for each character information item the
Unicode character specified by the [character code] property is added to the
[value] property of the base name item created by the parent baseName
element.
Ed. Note:
If normalization is required, that must be mentioned here.
If the baseNameString
element has an id
attribute that attribute is ignored.
variant
element The variant
element causes a variant item to be created and added to the [variants]
property of the base name item created by its baseName
ancestor.
If the variant
element has an id
attribute a locator item is created, with the [notation] property set
to "URI"
and the [address] property set to the URI of the baseName
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the variant item.
The [scope] property is initialized to the value of the [scope]
property of the variant or base name item created by the parent element (which
will be either a baseName
element or a variant
element). (It is implied that the parameters
or scope
element of the parent has already been processed.)
variantName
element The variantName
element has no direct effect on the information set being produced, but
changes the interpretation of its child element. The child element is processed
as follows:
If the child element is a resourceRef
element an absolute URI is produced from the value of its xlink:href
attribute, according to the rules of 3.1.2 Computing absolute URIs. From
this URI a locator item is produced (with [notation] set to "URI"
and [reference] set to the URI) and set as the value of the [resource]
property of the new variant item.
If the child element is a resourceData
element the information items in the [children] property of the element
item are traversed, and for each character information item the Unicode
character specified by the [character code] property is added to the [value]
property of the variant item created by the parent variant
element.
If the variantName
element has an id
attribute that attribute is ignored.
parameters
element The parameters
element has no direct effect on the information set being produced, but
changes the interpretation of its child elements. The child elements are
processed as follows:
Each topicRef
element causes a topic item to be added to the [scope] property of the
variant item created by the parent variant
element. The topic item is produced from the topicRef
element according to the rules of 3.15
The topicRef element.
Each subjectIndicatorRef
element causes a topic item to be added to the [scope] property of the
variant item created by the parent variant
element. The topic item is produced from the subjectIndicatorRef
element according to the rules of
3.16 The subjectIndicatorRef
element.
If the parameters
element has an id
attribute that attribute is ignored.
scope
element The scope
element has no direct effect on the information set being produced, but
changes the interpretation of its child elements. The child elements are
processed as follows:
Each topicRef
element causes a topic item to be added to the [scope] property of the
information item created by the parent element. The topic item is produced from
the topicRef
element according to the rules of 3.15
The topicRef element.
Each subjectIndicatorRef
element causes a topic item to be added to the [scope] property of the
information item created by the parent element. The topic item is produced from
the subjectIndicatorRef
element according to the rules of
3.16 The subjectIndicatorRef
element.
Each resourceRef
element causes a topic item to be added to the [scope] property of the
information item created by the parent element. The topic item is produced from
the resourceRef
element according to the rules of 3.17 The resourceRef element.
If the scope
element has an id
attribute that attribute is ignored.
instanceOf
element The instanceOf
element has no direct effect on the information set being produced, but
changes the interpretation of its child elements. The exact interpretation
depends on the parent element of the instanceOf
element, however.
Regardless of what parent element the instanceOf
element is found in, the child element produces a topic item. If it is
a topicRef
element the procedure in 3.15 The
topicRef element is followed; if it is a subjectIndicatorRef
element the procedure in 3.16 The subjectIndicatorRef
element is followed.
If the parent element is an occurrence
or association
elment, the produced topic item is set as the value of the [association
type] or [occurrence type] property of the information item produced by the
parent element.
If the parent element is a topic
element a new association item is created, with two association role
items in its [association roles] property. The topic item representing the
class-instance association type (described in
The Standard
Application Model, 5.1 The type-instance relationship) is set as the value
of its [association type] property.
The first association role item has its [role type] property set to the topic item representing the class role in the same association (see the section referenced above), while the [role playing topic] property is set to the topic produced by the child element.
The second association role item has its [role type] property set to the topic item representing the instance role in the same association (see the section referenced above), while the [role playing topic] property is set to the topic produced by the parent element (that is, the current topic).
Ed. Note:
This section must be made more formal.
If the instanceOf
element has an id
attribute that attribute is ignored.
occurrence
element The occurrence
element causes an occurrence item to be created, and added to the
[occurrences] property of the topic item created by the parent topic
element.
If the occurrence
element has an id
attribute a locator item is created, with the [notation] property set
to "URI"
and the [address] property set to the URI of the baseName
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the occurrence item.
If the occurrence
element has a resourceData
child element the information items in the [children] property of that
element item are traversed, and for each character information item the Unicode
character specified by the [character code] property is added to the [value]
property of the occurrence item created by the parent occurrence
element.
If the occurrence
element has a resourceRef
child element an absolute URI is produced from the value of its xlink:href
attribute, according to the rules of 3.1.2 Computing absolute URIs. From
this URI a locator item is produced (with [notation] set to "URI"
and [reference] set to the URI) and set as the value of the [resource]
property of the new occurrence item.
association
element The association
element causes an association item to be created, and added to the
[association] property of the topic map item.
If the association
element has an id
attribute a locator item is created, with the [notation] property set
to "URI"
and the [address] property set to the URI of the baseName
element, as defined in 3.1.1 Computing
the URI of an element. This locator item is added to the [source
locators] property of the association item.
member
element The member
element does not have any direct impact on the information set being
created, but affects the processing of its descendant elements.
For each topicRef
child of the member
element a topic item is produced according to the rules of
3.15 The topicRef element. An
association role item is created, and this topic item is then set as the value
of its [role playing topic] property. The association role item is then added
to the [association roles] property of the association item.
For each subjectIndicatorRef
child of the member
element a topic item is produced according to the rules of
3.16 The subjectIndicatorRef
element. An association role item is created, and this topic item is
then set as the value of its [role playing topic] property. The association
role item is then added to the [association roles] property of the association
item.
For each resourceRef
child of the member
element a topic item is produced according to the rules of
3.17 The resourceRef element. An
association role item is created, and this topic item is then set as the value
of its [role playing topic] property. The association role item is then added
to the [association roles] property of the association item.
If the member
element has a roleSpec
child element, which again has a topicRef
element, a topic item is produced according to the rules of
3.15 The topicRef element. That topic
item is then set as the value of the [role type] property of each association
role item produced above.
If the member
element has a roleSpec
child element, which again has a subjectIndicatorRef
element, a topic item is produced from that element according to the
rules of 3.16 The
subjectIndicatorRef element. That topic item is then set as the value
of the [role type] property of each association role item produced above.
If the member
element has an id
attribute its value is ignored.
topicRef
element The topicRef
element always produces a topic item, as described below. How the topic
item is used depends on the context in which the topicRef
element appears, and is described in the part of this document
describing the processing of the topicRef
element's parent element.
From the topicRef
element a locator item is produced with the [notation] property set to "URI"
, and the [address] property set to the absolute form of the URI in the
element's xlink:href
attribute. That absolute form is computed according to the rules in
3.1.2 Computing absolute URIs.
If the topic map processor has not already processed the information resource referred to by the URI (as identified by the part of the URI before the fragment identifier) that information resource is processed.
Ed. Note:
Describe how this processing is done.
If the information set has a topic item whose [subject
identifiers] or [source locators] properties contain a locator item equal to
the one produced above that topic item is the one produced by this topicRef
element.
If no such topic item exists, a topic item is created, and the
locator item added to its [source locators] property. That topic item is then
the one produced by this topicRef
element.
If the topicRef
element has an id
attribute that attribute is ignored.
subjectIndicatorRef
element The subjectIndicatorRef
element produces a topic item, as described below. How the topic item
is used depends on the context in which the subjectIndicatorRef
element appears, and is described in the part of this document
describing the processing of the subjectIndicatorRef
element's parent element.
From the subjectIndicatorRef
element a locator item is produced with the [notation] property set to "URI"
, and the [address] property set to the absolute form of the URI in the
element's xlink:href
attribute. That absolute form is computed according to the rules in
3.1.2 Computing absolute URIs.
If the information set has a topic item whose [subject
identifiers] or [source locators] properties contain a locator item equal to
the one produced above that topic item is the one produced by this subjectIndicatorRef
element.
If no such topic item exists, a topic item is created, and the
locator item added to its [subject identifiers] property. That topic item is
then the one produced by this subjectIndicatorRef
element.
If the subjectIndicatorRef
element has an id
attribute that attribute is ignored.
resourceRef
element The resourceRef
element produces a topic item, as described below. How the topic item
is used depends on the context in which the resourceRef
element appears, and is described in the part of this document
describing the processing of the resourceRef
element's parent element.
From the resourceRef
element a locator item is produced with the [notation] property set to "URI"
, and the [address] property set to the absolute form of the URI in the
element's xlink:href
attribute. That absolute form is computed according to the rules in
3.1.2 Computing absolute URIs.
If the information set has a topic item whose [subject address]
property contains a locator item equal to the one produced above that topic
item is the one produced by this resourceRef
element.
If no such topic item exists, a topic item is created, and the
locator item set as the value of its [subject address] property. That topic
item is then the one produced by this resourceRef
element.
If the resourceRef
element has an id
attribute that attribute is ignored.
mergeMap
element An absolute URI is produced from the mergeMap
element's xlink:href
attribute, following the procedure in
3.1.2 Computing absolute URIs. If
the information resource referred to by that URI has already been processed
nothing further is done. If it has not the procedure below is followed.
Issue (xtm-mergeMap-and-topicRef):
What is the correct behaviour if a topicRef
to an external document occurs first, followed by a mergeMap
with added themes?
First, the information resource referred to is parsed into a
representation of the XML Information Set, then one element item from that
information set is used to produce a SAM instance, as described in
3 Deserialization. If the URI does
not have a fragment identifier the element in the [document element] property
of the document information item is chosen as the element item to use as the
input to the deserialization process. If the URI does have a fragment
identifier the element item in the [owner element] property of the attribute
whose [local name] property is set to "id"
and whose [normalized value] property has the same value as the
fragment identifier is chosen. In both cases, if this element is not a topicMap
element an error is reported.
For each topicRef
child element of the mergeMap
element the topic item produced by the procedure of
3.15 The topicRef element is added to
the [scope] property of every information item in the SAM instance produced
above.
For each subjectIndicatorRef
child element of the mergeMap
element the topic item produced by the procedure of
3.16 The subjectIndicatorRef
element is added to the [scope] property of every information item in
the SAM instance produced above.
For each resourceRef
child element of the mergeMap
element the topic item produced by the procedure of
3.17 The resourceRef element is
added to the [scope] property of every information item in the SAM instance
produced above.
Finally, the SAM instance is merged into the current SAM instance, following the procedure described in SAM, 4.3 Merging topic maps. The existing SAM instance is the master topic map, while the new SAM instance is the subordinate topic map.
If the mergeMap
element has an id
attribute that attribute is ignored, as is the value of its xlink:type
attribute.
A topic map processor conforms to this specification provided that it meets all the requirements given below.
The topic map processor must reject information resources which are not well-formed XML from deserialization, as well as XML documents that are not valid according to the XTM 1.0 DTD.
The topic map processor must reject all XTM topic maps which do not conform to the constraints listed as 'XTM constraints' in this international standard.
The topic map processor must reject all XTM topic maps which after deserialization produce SAM model instances that violate one of the constraints labelled as 'SAM constraints' in [SAM].
The topic map processor must be able to deserialize conforming XTM topic maps and then serialize the result back to an XTM topic map that is logically equivalent to the original.
Ed. Note:
Define what "logically equivalent" means.
<!-- ............................................................. --> <!-- XML Topic Map DTD .......................................... --> <!-- file: xtm1.dtd --> <!-- XML Topic Map (XTM) DTD, Version 1.0 This is XTM, an XML interchange syntax for ISO 13250 Topic Maps. Use this URI to identify the default XTM namespace: "http://www.topicmaps.org/xtm/1.0/" Used to identify the XLink namespace: "http://www.w3.org/1999/xlink" --> <!-- topicMap: Topic Map document element ........................ --> <!ELEMENT topicMap ( topic | association | mergeMap )* > <!ATTLIST topicMap id ID #IMPLIED xmlns CDATA #FIXED 'http://www.topicmaps.org/xtm/1.0/' xmlns:xlink CDATA #FIXED 'http://www.w3.org/1999/xlink' xml:base CDATA #IMPLIED > <!-- topic: Topic element ........................................ --> <!ELEMENT topic ( instanceOf*, subjectIdentity?, ( baseName | occurrence )* ) > <!ATTLIST topic id ID #REQUIRED > <!-- instanceOf: Points To a Topic representing a class .......... --> <!ELEMENT instanceOf ( topicRef | subjectIndicatorRef ) > <!ATTLIST instanceOf id ID #IMPLIED > <!-- subjectIdentity: Subject reified by Topic ................... --> <!ELEMENT subjectIdentity ( resourceRef?, ( topicRef | subjectIndicatorRef )* ) > <!ATTLIST subjectIdentity id ID #IMPLIED > <!-- topicRef: Reference to a Topic element ...................... --> <!ELEMENT topicRef EMPTY > <!ATTLIST topicRef id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED > <!-- subjectIndicatorRef: Reference to a Subject Indicator ....... --> <!ELEMENT subjectIndicatorRef EMPTY > <!ATTLIST subjectIndicatorRef id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED > <!-- baseName: Base Name of a Topic .............................. --> <!ELEMENT baseName ( scope?, baseNameString, variant* ) > <!ATTLIST baseName id ID #IMPLIED > <!-- baseNameString: Base Name String container .................. --> <!ELEMENT baseNameString ( #PCDATA ) > <!ATTLIST baseNameString id ID #IMPLIED > <!-- variant: Alternate forms of Base Name ....................... --> <!ELEMENT variant ( parameters, variantName?, variant* ) > <!ATTLIST variant id ID #IMPLIED > <!-- variantName: Container for Variant Name ..................... --> <!ELEMENT variantName ( resourceRef | resourceData ) > <!ATTLIST variantName id ID #IMPLIED > <!-- parameters: Processing context for Variant .................. --> <!ELEMENT parameters ( topicRef | subjectIndicatorRef )+ > <!ATTLIST parameters id ID #IMPLIED > <!-- occurrence: Resources regarded as an Occurrence ............. --> <!ELEMENT occurrence ( instanceOf?, scope?, ( resourceRef | resourceData ) ) > <!ATTLIST occurrence id ID #IMPLIED > <!-- resourceRef: Reference to a Resource ........................ --> <!ELEMENT resourceRef EMPTY > <!ATTLIST resourceRef id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED > <!-- resourceData: Container for Resource Data ................... --> <!ELEMENT resourceData ( #PCDATA ) > <!ATTLIST resourceData id ID #IMPLIED > <!-- association: Topic Association ............................. --> <!ELEMENT association ( instanceOf?, scope?, member+ ) > <!ATTLIST association id ID #IMPLIED > <!-- member: Member in Topic Association ......................... --> <!ELEMENT member ( roleSpec?, ( topicRef | resourceRef | subjectIndicatorRef )* ) > <!ATTLIST member id ID #IMPLIED > <!-- roleSpec: Points to a Topic serving as an Association Role .. --> <!ELEMENT roleSpec ( topicRef | subjectIndicatorRef ) > <!ATTLIST roleSpec id ID #IMPLIED > <!-- scope: Reference to Topic(s) that comprise the Scope ........ --> <!ELEMENT scope ( topicRef | resourceRef | subjectIndicatorRef )+ > <!ATTLIST scope id ID #IMPLIED > <!-- mergeMap: Merge with another Topic Map ...................... --> <!ELEMENT mergeMap ( topicRef | resourceRef | subjectIndicatorRef )* > <!ATTLIST mergeMap id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED > <!-- end of XML Topic Map (XTM) 1.0 DTD --> |
This section provides useful information on how to serialize SAM instances using the XTM syntax. The main text of this specification already provides the constraints necessary to ensure interoperability, but as serialization is not entirely straightforward, this section provides additional guidance for implementors.
Ed. Note:
Needs to be written.