| TITLE: | CD 13250-3: Information Technology - Document Description and Processing Languages, Topic Maps - XML Syntax |
| SOURCE: | Mr. Lars Marius Garshol; Mr. Graham Moore |
| PROJECT: | CD 13250-3: Information Technology - Document Description and Processing Languages, Topic Maps - XML Syntax |
| PROJECT EDITOR: | Mr. Lars Marius Garshol; Mr. Graham Moore |
| STATUS: | CD text |
| ACTION: | CD ballot |
| DATE: | 2004-03-16 |
| DISTRIBUTION: | SC34 and Liaisons |
| REFER TO: | N0495b - 2004-03-29 - Ballot Due 2004-06-29 CD 13250-3: Information Technology - Document Description and Processing Languages, Topic Maps - XML Syntax |
| REPLY TO: |
Dr. James David Mason (ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada) Crane Softwrights Ltd. Box 266, Kars, ON K0A-2E0 CANADA Telephone: +1 613 489-0999 Facsimile: +1 613 489-0995 Network: jtc1sc34@scc.ca http://www.jtc1sc34.org |
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
ISO/IEC 13250-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 34, Document Description and Processing Languages.
ISO/IEC 13250 consists of the following parts, under the general title Topic Maps:
XTM 1.1 is a syntax for the interchange of topic maps. 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. Ease of human XTM authoring was not prioritized during the design of the syntax, and consequently it is not recommended to edit the syntax directly.
The interpretation of the XTM syntax is defined through a mapping from the syntax to the data model defined in [ISO 13250-2]. Informative guidance on how to serialize instances of the data model to the XTM syntax is also provided.
Issue (xtm-reserialization-recommendation):
Should the specification have a non-normative section providing guidance for implementors on how to do reserialization properly?
Issue (xtm-external-ref-failure):
What happens when external references from an XTM document fails? Note that only topicRef and mergeMap references can fail, since these are the only references followed by an XTM processor.
This part of ISO/IEC 13250 defines an XML-based interchange syntax for topic maps, which can be used to interchange instances of the data model defined in [ISO 13250-2]. It also defines a mapping from the interchange syntax to the data model. The syntax is defined with a RELAX-NG schema, and more precision is provided through the mapping to the data model, which effectively also defines the interpretation of the syntax.
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Each of the following documents has a unique identifier that is used to cite the document in the text. The unique identifier consists of the part of the reference up to the first comma.
ISO 13250-2, Topic Maps — Data Model, http://www.isotopicmaps.org/sam/
W3C XML, Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000, http://www.w3.org/TR/2000/REC-xml-20001006
W3C XML-Names, Namespaces in XML, W3C Recommendation, 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114/
W3C XLink, XML Linking Language (XLink) Version 1.0, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/
W3C XBase, XML Base (XBase) Version 1.0, W3C Recommendation, 27 June 2001, http://www.w3.org/TR/2001/REC-xmlbase-20010627/
W3C XPointer, XPointer Framework Version 1.0, W3C Recommendation, 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
W3C XML-Infoset, XML Information Set, W3C Recommendation, 24 October 2001, http://www.w3.org/TR/2001/REC-xml-infoset-20011024/
ISO 19757-2, Document Schema Definition Languages (DSDL) — Part 2: Grammar-based validation — RELAX NG, http://www.relaxng.org
IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, Internet Standards Track Specification, August 1998, http://www.ietf.org/rfc/rfc2396.txt
IETF RFC 2732, Format for Literal IPv6 Addresses in URLs, Internet Standards Track Specification, December 1999, http://www.ietf.org/rfc/rfc2732.txt
XTM1.0, XML Topic Maps (XTM) 1.0 Specification, Steve Pepper, Graham Moore, TopicMaps.Org, 2001, http://www.topicmaps.org/xtm/1.0/
For the purposes of this part of ISO/IEC 13250, the following terms and definitions apply.
the data model defined in [ISO 13250-2]
the process of building an instance of an implementation's internal representation of the data model from an instance of a topic map syntax
The process of exporting topic maps from an implementation's internal representation of the data model to an instance of a topic map syntax
an XML document that contains one or more XTM topic maps
a topic map represented in XTM syntax as a topicMap element with descendants
This clause defines the XTM syntax, which is an interchange syntax for topic maps, using prose and a RELAX-NG schema in compact syntax [ISO 19757-2]. The full schema can be found in Annex A, together with informative schemas in other schema languages.
An XTM topic map is a topic map represented in XTM syntax as a topicMap element with descendants. An XTM document is an XML document that contains one or more XTM topic maps.
An XML document is a valid XTM document provided it conforms to [W3C XML-Names] and all XTM topic maps within it are valid. An XTM topic map is valid provided:
It conforms to the schema in Annex A.
It can be deserialized according to the procedure defined in Clause 5 without causing any errors or violating any data model constraints.
The document element of an XTM document need not be a topicMap element, since this definition allows XML topic maps to be contained within other markup.
The XTM syntax represents all references as simple XLinks conformant to the XLink specification [W3C XLink]. However, since the xlink:type attribute is not required XML documents can be valid XTM documents without being valid according to XLink. The inclusion of the xlink:type attribute on all XLink elements is encouraged for compatibility.
The following declarations are used throughout the schema for brevity.
default namespace = "http://www.topicmaps.org/xtm/1.0/"
namespace xlink = "http://www.w3.org/1999/xlink"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
start = topicMap
topic-reference = topicRef | resourceRef | subjectIndicatorRef
id = attribute id { xsd:ID }
href = attribute xlink:href { xsd:anyURI }
type = attribute xlink:type { "simple" }
any-markup = (text | element * - xtm:* { attribute * { text }?, any-markup* })* |
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:
topicMap = element topicMap { id?, xmlbase?, version,
(topic | association | mergeMap)* }
id = attribute id { xsd:ID }
xmlbase = attribute xml:base { xsd:anyURI }
version = attribute version { "1.1" } |
The attributes have the following meanings:
A unique identifier for the topic map within the document. Used to refer to the topic map.
The version number of the XTM syntax to which the document conforms. For XTM 1.1 documents this must be "1.1".
An attribute used to override the base URI of the document inside the topicMap element, as specified in [W3C XBase].
Implementations of XTM 1.1 are required to also support XTM 1.0 documents. It is assumed that any XTM document that does not have a version attribute on the topicMap element is an XTM 1.0 document. XTM 1.0 documents are mapped to the data model in the same way as XTM 1.1 documents, but follow the XTM 1.0 DTD rather than the RELAX-NG schema of XTM 1.1.
An XTM 1.0 document is considered valid provided:
It conforms to [XTM1.0].
It conforms to [W3C XML-Names].
It can be deserialized according to the procedure defined in Clause 5 without causing any errors or violating any data model constraints.
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:
topic = element topic { id, instanceOf*, subjectIdentity?, (baseName | occurrence)* } |
The id attribute provides a unique identifier for the topic, which is used to refer to it.
The subjectIdentity element type may in its child elements contain formal declarations of the subject of the topic defined by the parent element.
The subjectIdentity element type is declared as follows:
subjectIdentity =
element subjectIdentity { resourceRef?, ( topicRef | subjectIndicatorRef )* } |
The id attribute is ignored during deserialization.
The baseName element type is used to add topic names to the topic created by the parent topic element. The child elements of the baseName element provide the property values of the topic name item.
The baseName element type is declared as follows:
baseName = element baseName { id?, instanceOf?, scope?, baseNameString, variant* } |
The id attribute provides a unique identifier for the topic name, which can be used to refer to it.
The baseNameString element type is used to provide the value of the base name.
The baseNameString element type is declared as follows:
baseNameString = element baseNameString { id?, any-markup } |
The id attribute is ignored during deserialization.
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:
variant = element variant { id?, parameters, variantName?, variant* } |
The id attribute provides a unique identifier for the variant name, which is used to refer to it.
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:
variantName = element variantName { id?, (resourceRef | resourceData) } |
The id attribute is ignored during deserialization.
The parameters element type is used to specify the scope of a variant name, in addition to the scope it inherits from its parent topic name or variant name.
The parameters element type is declared as follows:
parameters = element parameters { id?, topic-reference+ } |
The id attribute is ignored during deserialization.
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:
scope = element scope { id?, topic-reference+ } |
The id attribute is ignored during deserialization.
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:
instanceOf = element instanceOf { id?, topic-reference } |
The id attribute is ignored during deserialization.
The occurrence element type is used to assign an occurrence to the topic defined by the parent element.
The occurrence element type is declared as follows:
occurrence = element occurrence { id?,
instanceOf?, scope?, ( resourceRef | resourceData ) } |
The id attribute is used to refer to the occurrence.
The resourceData element type is used to provide an information resource in the form of content 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:
resourceData = element resourceData { id?, any-markup } |
The id attribute is ignored during deserialization.
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:
association = element association { id?, instanceOf?, scope?, member+ } |
The id attribute is used to refer to the association.
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:
member = element member { id?, roleSpec?, topic-reference* } |
The id attribute is ignored when there is more than one topic reference child, but used to refer to the member element when there is one or zero such children.
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:
roleSpec = element roleSpec { id?, topic-reference } |
The id attribute is ignored during deserialization.
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:
topicRef = element topicRef { id?, href, type? } |
The attributes have the following meanings:
This attribute is ignored during deserialization.
Contains the URI reference that is the topic reference. This URI reference must conform to the requirements of XLink and have a fragment identifier which must be what [W3C XPointer] calls a shorthand pointer (formerly barename).
This attribute, if included, declares the topicRef element to be a simple XLink link.
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:
subjectIndicatorRef = element subjectIndicatorRef { id?, href, type? } |
The attributes have the following meanings:
This attribute is ignored during deserialization.
Contains the URI reference of the subject indicator being referred to. The URI reference must conform to the requirements of XLink. If this URI reference contains a fragment identifier the fragment identifier must be what [W3C XPointer] calls a shorthand pointer (formerly barename).
This attribute, if included, declares the subjectIndicatorRef element to be a simple XLink link.
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:
resourceRef = element resourceRef { id?, href, type? } |
The attributes have the following meanings:
This attribute is ignored during deserialization.
Contains the URI reference of the information resource being referred to. The URI reference must conform to the requirements of XLink. If this URI reference contains a fragment identifier the fragment identifier must be what [W3C XPointer] calls a shorthand pointer (formerly barename).
This attribute, if included, declares the resourceRef element to be a simple XLink link.
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:
mergeMap = element mergeMap { id?, href, type?, topic-reference* } |
The attributes have the following meanings:
This attribute is ignored during deserialization.
This attribute declares the mergeMap element to be a simple XLink element.
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 XML document that contains at least one topicMap element. The URI reference must conform to the requirements of XLink. If it has a fragment identifier that identifier must be what [W3C XPointer] calls a shorthand pointer (formerly barename).
This attribute, if included, declares the mergeMap element to be a simple XLink link.
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?
The process of exporting topic maps from an implementation's internal representation of the data model to an instance of a topic map syntax is known as serialization. The opposite process, deserialization is the process of building an instance of an implementation's internal representation of the data model from an instance of a topic map syntax. This part of ISO/IEC 13250 defines how to deserialize XTM documents in Clause 5, and serialization is implicitly defined.
This clause defines how instances of the XTM syntax are deserialized into instances of the data model. The data model is the data model defined in [ISO 13250-2].
The input to the deserialization process is:
An element item as defined by [W3C XML-Infoset], representing a topicMap element. 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 part of ISO/IEC 13250.
An absolute URI. This is the URI from which the XML document was retrieved, known as the document URI. This URI must always be provided, as it is necessary in order to assign the source locators of the information items created during deserialization. If the XML document was not read from any particular URI the application is responsible for providing a URI it considers suitable.
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 clause about that
element type are performed. An input element item matches a clause 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.
The definition of the string type in [ISO 13250-2] requires that all strings created during deserialization be represented using Unicode Normalization Form C.
This deserialization algorithm requires an instance of the XML Information Set as input, but in most cases the actual input will be an XML document. This part of ISO/IEC 13250 does not constrain how XML Information Set instances are built from XML documents, but assumes that in most cases this will be done by simply using an XML parser.
XML parsers conformant to the XML Recommendation may produce different results given the same XML document, depending on whether they are validating or non-validating, and depending on which optional features they support. Reliance on any particular behaviour in the XML parsers used by recipients is strongly discouraged.
It is explicitly allowed to apply pre-processing to an XML document in order to build an XTM-conformant XML Information Set instance from it, for example by applying architectural forms processing or XSLT stylesheets .
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 concatenating the document URI, a
"#" 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".
Finally, a locator item is created, with its [notation] property set
to "URI" and the URI in its [reference] property.
Creation of a locator item from an element information item in the XML Infoset is done by:
locating the attribute information item in the element's
[attributes] property whose [namespace name] property is set to
"http://www.w3.org/1999/xlink" and whose [local name]
property is set to "href",
the value of the attribute information item's [normalized value]
property is unescaped by replacing %HH escape sequences
with the characters they represent, and the resulting character
sequence is decoded from UTF-8 to a sequence of abstract Unicode
characters,
the resulting string is turned into an absolute URI by resolving it against the URI in the [base URI] property of the element information item, and
finally a locator item is created with its [notation] property set
to "URI" and its [reference] property set to the URI
produced by the previous step.
Dependency on the xtm-same-doc-refs issue here.
Whenever a new information item is created, those of its properties which have set values are set to the empty set, while the other properties are initialized to null.
The URI to the external information resource is resolved and the result is parsed with an XML parser according to to produce an XML Information Set according to [W3C XML-Infoset]. It is an error if the information resource cannot be retrieved or if the result is not a well-formed XML document.
The XML Information Set is then traversed to find element items that match section 5.4 and for each element item found a Data Model instance is built using the procedure in Clause 5 with the element item and the URI of the information resource as input. The Data Model instances are then returned as the result of processing.
A topic map item B loaded from an external reference can be merged into another topic map item A currently being deserialized by:
Adding all topic items in B's [topics] property to A's [topics] property.
Adding all association items in B's [associations] property to A's [associations] property.
Adding topics and associations to A is may trigger further merges, as described in [ISO 13250-2].
The topicMap element causes a topic map item to be created.
If the topicMap element has an id attribute a locator item is created, as defined in 5.3.2, and 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 data model instance being built, except insofar as it modifies the input XML Information Set.
If the topicMap element has an version attribute
its value must be 1.1, indicating an XTM 1.1 document. It
is an error for the value to be anything else. If the attribute is not
present the document is assumed to be an XTM 1.0 document, and
processed accordingly.
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, as defined in 5.3.2, and added to the [source locators] property of the topic item.
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 according to the procedure described in 5.3.3. That locator item is then added to the [subject addresses] property of the topic item created by the parent topic element.
For every subjectIndicatorRef child, a locator item is produced according to the procedure described in 5.3.3. That locator item is then added to the [subject identifiers] property of the topic item created by the parent topic element.
For every topicRef child a topic item is produced according to the rules of 5.17. That topic item is then merged with the topic item created from the parent topic element according to the rules of ISO/IEC 13250, Part 2, 6.2.
If the subjectIdentity element has an id attribute that attribute is ignored.
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, as defined in 5.3.2, and added to the [source locators] property of the base name item.
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.
Update once we know how to represent XML in the DM.
If the baseNameString element has an id attribute that attribute is ignored.
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, as defined in 5.3.2, and 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 here assumed that the scope of the parent element has already been processed, which it will have been, so long as the document is valid.
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 a locator item is produced from it following the procedure in 5.3.3. This locator item is 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.
Update when representation of XML data in DM decided.
If the variantName element has an id attribute that attribute is ignored.
The parameters element has no direct effect on the information set being produced, but changes the interpretation of its child elements. Each topicRef, resourceRef, and subjectIndicatorRef child element is processed according to the rules for that element type to produce a topic item. These topic items are gathered into a set that is assigned as the value of the [scope] property of the variant item produced by the parent element.
If the parameters element has an id attribute that attribute is ignored.
The scope element has no direct effect on the information set being produced, but changes the interpretation of its child elements. Each topicRef, resourceRef, and subjectIndicatorRef child element is processed according to the rules for that element type to produce a topic item. These topic items are gathered into a set that is assigned as the value of the [scope] property of the information item produced by the parent element.
If the scope element has an id attribute that attribute is ignored.
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 5.17 is followed; if it is a resourceRef element the procedure in 5.19 is followed; if it is a subjectIndicatorRef element the procedure in 5.18 is followed.
If the parent element is a baseName, occurrence, or association element, the produced topic item is set as the value of the [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 type-instance association type (described in ISO/IEC 13250, Part 2, 7.2.
The first association role item has its [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 [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).
If the instanceOf element has an id attribute that attribute is ignored.
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, as defined in 5.3.2, 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.
Update when representation of XML data in DM decided.
If the occurrence element has a resourceRef child element a locator item is produced from it according to the rules of 5.3.3. This locator is set as the value of the [resource] property of the new occurrence item.
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, as defined in 5.3.2, and added to the [source locators] property of the association item.
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, resourceRef, and subjectIndicatorRef child of the member element a topic item is produced according to the rules for its element type. 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 no topicRef, subjectIndicatorRef, or resourceRef children a new association role item is created anyway. A new topic item is created and set as the value of its [role playing topic] property, and 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, resourceRef, or subjectIndicatorRef child element, a topic item is produced according to the rules for its element type. That topic item is then set as the value of the [type] property of each association role item produced above.
If the member element no roleSpec child element a new topic item is created and set as the value of the [type] property of each association role item produced above.
If the member element has an id and no more than one topicRef, subjectIndicatorRef, resourceRef child, a locator item is created, as defined in 5.3.2, and added to the [source locators] property of the association role item.
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 according to the rules in 5.3.3. If the locator item refers to an external resource it is processed according to the rules in 5.20 as though it were a mergeMap element with an empty added scope.
After processing the reference, 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.
What if the topicRef element refers to a topic in an external resource where the topicMap element is not the document element. Is that an error? What if there is more than one topicMap 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 according to the rules in 5.3.3. 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.
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 according to the rules in 5.3.3. If the information set has a topic item whose [subject addresses] 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 add to its [subject addresses] 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.
An absolute URI is produced from the mergeMap element's xlink:href attribute, following the procedure in 5.3.3. For each topicRef, resourceRef, and subjectIndicatorRef child element of the mergeMap element a topic item produced is produced as described in the section for that element type. The set of topic items thus produced is known as the added scope of this reference.
If the information resource referred to by the given URI has already been processed with an equal added scope nothing further is done. If it has not a set of data model instances is produced as described in 5.3.5. After this there are two possibilities:
If the URI has a fragment identifier the data model instance whose topic map item has the corresponding locator item in its [source locators] property is chosen. It is an error if there is no such data model instance.
If the URI has no fragment identifier it is an error if the set of data model instances does not have a single member. That member is then chosen.
Finally, each topic item in the added scope is added to the [scope] property of every information item in the data model instance produced above. Finally, the data model instance is merged into the current data model instance, following the procedure described in 5.3.6.
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.
The topic map processor must reject all XTM topic maps which are not valid.
For all XTM topic maps which are not rejected the topic map processor must build a representation that is isomorphic to the data model instance created by the procedure given in Clause 5.
# ===========================================================================
#
# XML Topic Maps 1.1
#
# This is the normative RELAX-NG schema for the XTM 1.1 syntax, as
# defined in ISO 13250-3.
#
# ===========================================================================
# --- Common declarations
default namespace = "http://www.topicmaps.org/xtm/1.0/"
namespace xlink = "http://www.w3.org/1999/xlink"
namespace xtm = "http://www.topicmaps.org/xtm/1.0/"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
start = topicMap
topic-reference = topicRef | resourceRef | subjectIndicatorRef
id = attribute id { xsd:ID }
href = attribute xlink:href { xsd:anyURI }
type = attribute xlink:type { "simple" }
any-markup = (text | element * - xtm:* { attribute * { text }?, any-markup* })*
# --- The schema
topicMap = element topicMap { id?, xmlbase?, version,
(topic | association | mergeMap)* }
xmlbase = attribute xml:base { xsd:anyURI }
version = attribute version { "1.1" }
topic = element topic { id, instanceOf*, subjectIdentity?, (baseName | occurrence)* }
subjectIdentity =
element subjectIdentity { resourceRef?, ( topicRef | subjectIndicatorRef )* }
baseName = element baseName { id?, instanceOf?, scope?, baseNameString, variant* }
baseNameString = element baseNameString { id?, any-markup }
variant = element variant { id?, parameters, variantName?, variant* }
variantName = element variantName { id?, (resourceRef | resourceData) }
parameters = element parameters { id?, topic-reference+ }
scope = element scope { id?, topic-reference+ }
instanceOf = element instanceOf { id?, topic-reference }
occurrence = element occurrence { id?,
instanceOf?, scope?, ( resourceRef | resourceData ) }
resourceData = element resourceData { id?, any-markup }
association = element association { id?, instanceOf?, scope?, member+ }
member = element member { id?, roleSpec?, topic-reference* }
roleSpec = element roleSpec { id?, topic-reference }
topicRef = element topicRef { id?, href, type? }
subjectIndicatorRef = element subjectIndicatorRef { id?, href, type? }
resourceRef = element resourceRef { id?, href, type? }
mergeMap = element mergeMap { id?, href, type?, topic-reference* }
# --- End of schema |
<!-- ....................................................................... -->
<!-- XML Topic Map DTD .................................................... -->
<!-- XML Topic Map (XTM) DTD, Version 1.1
This is XTM, an XML interchange syntax for ISO 13250 Topic Maps,
defined by ISO 13250-3.
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
version CDATA #FIXED '1.1'
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 | resourceRef | subjectIndicatorRef ) >
<!ATTLIST instanceOf
id ID #IMPLIED
>
<!-- subjectIdentity: Subject reified by Topic ................... -->
<!ELEMENT subjectIdentity
( topicRef | resourceRef | 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 ( instanceOf?, 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 | resourceRef | 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 | resourceRef | 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.1 DTD --> |
<?xml version="1.0" encoding="UTF-8"?>
<!--
Draft W3C XML Schema for XTM 1.1.
First version created by Max Voskob using XML Spy. This version
slightly modified by Lars Marius Garshol.
TODO:
- edit XLink support into same file
- make it use XTM namespace
- update with latest changes
- make XLink attributes fixed
- type xlink:href with anyURI
- baseNameString and resourceData look strange
- verify that it is correct
- see what can be done to make schema closed (i.e: outlaw
extensions)
- add xml:base
-->
<xs:schema xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/1999/xlink"
schemaLocation="xlink.xsd"/>
<!-- topicMap ........................................................... -->
<xs:element name="topicMap">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="topic"/>
<xs:element ref="association"/>
<xs:element ref="mergeMap"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- topic .............................................................. -->
<xs:element name="topic">
<xs:complexType>
<xs:sequence>
<xs:element ref="instanceOf" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="subjectIdentity" minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="baseName"/>
<xs:element ref="occurrence"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<!-- instanceOf ......................................................... -->
<xs:element name="instanceOf">
<xs:complexType>
<xs:choice>
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- subjectIdentity .................................................... -->
<xs:element name="subjectIdentity">
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- topicRef ........................................................... -->
<xs:element name="topicRef">
<xs:complexType>
<xs:attribute name="id" type="xs:ID"/>
<xs:attribute ref="xlink:type"/>
<xs:attribute ref="xlink:href" use="required"/>
</xs:complexType>
</xs:element>
<!-- subjectIndicatorRef ................................................ -->
<xs:element name="subjectIndicatorRef">
<xs:complexType>
<xs:attribute name="id" type="xs:ID"/>
<xs:attribute ref="xlink:type"/>
<xs:attribute ref="xlink:href" use="required"/>
</xs:complexType>
</xs:element>
<!-- baseName ........................................................... -->
<xs:element name="baseName">
<xs:complexType>
<xs:sequence>
<xs:element ref="instanceOf" minOccurs="0"/>
<xs:element ref="scope" minOccurs="0"/>
<xs:element ref="baseNameString"/>
<xs:element ref="variant" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- baseNameString ..................................................... -->
<xs:element name="baseNameString">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- variant ............................................................ -->
<xs:element name="variant">
<xs:complexType>
<xs:sequence>
<xs:element ref="parameters"/>
<xs:element ref="variantName" minOccurs="0"/>
<xs:element ref="variant" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- variantName ........................................................ -->
<xs:element name="variantName">
<xs:complexType>
<xs:choice>
<xs:element ref="resourceRef"/>
<xs:element ref="resourceData"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- parameters ......................................................... -->
<xs:element name="parameters">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- occurrence ......................................................... -->
<xs:element name="occurrence">
<xs:complexType>
<xs:sequence>
<xs:element ref="instanceOf" minOccurs="0"/>
<xs:element ref="scope" minOccurs="0"/>
<xs:choice>
<xs:element ref="resourceRef"/>
<xs:element ref="resourceData"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- resourceRef ........................................................ -->
<xs:element name="resourceRef">
<xs:complexType>
<xs:attribute name="id" type="xs:ID"/>
<xs:attribute ref="xlink:type"/>
<xs:attribute ref="xlink:href" use="required"/>
</xs:complexType>
</xs:element>
<!-- resourceData ....................................................... -->
<xs:element name="resourceData">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- association ........................................................ -->
<xs:element name="association">
<xs:complexType>
<xs:sequence>
<xs:element ref="instanceOf" minOccurs="0"/>
<xs:element ref="scope" minOccurs="0"/>
<xs:element ref="member" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- member ............................................................. -->
<xs:element name="member">
<xs:complexType>
<xs:sequence>
<xs:element ref="roleSpec" minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- roleSpec ........................................................... -->
<xs:element name="roleSpec">
<xs:complexType>
<xs:choice>
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- scope .............................................................. -->
<xs:element name="scope">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
</xs:element>
<!-- mergeMap ........................................................... -->
<xs:element name="mergeMap">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="topicRef"/>
<xs:element ref="resourceRef"/>
<xs:element ref="subjectIndicatorRef"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
<xs:attribute ref="xlink:type"/>
<xs:attribute ref="xlink:href" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
|
This section provides information on how to serialize Data Model 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.
Generally, a serialization implementation should guarantee that for any data model instance the XTM serialization produced by the implementation should when deserialized to a new data model instance produce one that has the same canonicalization as the original data model instance, according to ISO 13250-4[2].
Serialization is for the most part straightforward, though care must be taken to preserve any reification relationships in the original data model instance. Implementations should also be careful not to make any assumptions about the XML implementation used to read the produced XTM document or what information resources (like DTDs) are available to the recipient of the XTM document.
This annex describes the differences between the syntax defined in this edition of ISO 13250 and that given in ISO/IEC 13250:2003[1].
The differences are:
The instanceOf element is now allowed inside the baseName element.
The resourceRef element is now allowed inside the parameters, instanceOf, and roleSpec elements.
The topicMap element now has a new version attribute.
Complete list.
ISO/IEC 13250:2003, Topic Maps, 2003, http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf
ISO 13250-4, Topic Maps — Canonicalization, http://www.isotopicmaps.org/sam/cxtm/