ISO/IEC JTC 1/SC34 N0266

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title:	Topic map foundational model requirements
Source:	Graham Moore, Lars Marius Garshol
Project:	Topic Map Models
Project editor:	Graham Moore, Lars Marius Garshol
Status:	Editors' Draft
Action:	For review and comment
Date:	30 October 2001
Summary:
Distribution:	SC34 and Liaisons
Refer to:	241, 242, 243, 244, 252, 261
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:[email protected] 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: [email protected]

Topic map foundational model requirements

Version:	0.1.0
Date:	2001-10-29
Editor:	Graham Moore, Empolis
Editor:	Lars Marius Garshol, Ontopia

This document contains a set of requirements for the work on the foundational model for topic maps, for the consideration of SC34 WG3 in particular and the user community in general. This document only covers the requirements to the so-called level 1 model, leaving the requirements on the level 0 model to the editors of that model.

The purpose of this requirements document is to document the editors' opinions on what the model should do and what form it should take. It is hoped that this will enable the user community to make their opinions known to the editors before work begins in earnest. The feedback of all interested parties is therefore very strongly requested, either by mail to the editors, or, preferrably, by mail to the topicmapmail list. National bodies may wish to send their comments via the ISO secretariat.

1. Terminology

The following topic map terms will be used in this document as defined here.

topic map processing: The processing of topic map information by software in any way for any purpose whatsoever.
topic map parsing: The process of building some program-internal representation of a topic map from a topic map serialized in some format.

Throughout this document the following key words are used to indicate the extent to which the editors consider themselves bound by each requirement.

shall: Means that the requirement is absolute.
should: Means that the requirement is a goal.
may: Means that the requirement is considered important, but that it is not yet clear whether the data model should conform to it or not.

2. General requirements

The main requirements on the foundational model are listed below.

The foundational model shall define the structure of topic maps that in a way that is independent of any particular syntax. This definition shall take the form of a data model, defined using the infoset formalism with accompanying UML diagrams.
The foundational model specification shall not unduly constrain the internal aspects of topic map implementations.
The foundational model shall not be limited to a web environment or a HyTime environment, but shall work within both.
The text of the foundational model specification shall be as readable and concise as precision will allow.
The foundational model shall describe the structure of topic maps and the process of parsing them in such a way that conformant implementations will be interoperable.
The foundational model may contain prose explaining the semantics of data model instances.

3. Data model requirements

The requirements on the data model part of the foundational model are described below.

The data model shall define all logically relevant aspects of topic map information (including all strings and locators). Anything that is not explicitly part of the model shall not considered to be part of topic maps.
The data model shall define all uniqueness constraints, value constraints, and structural constraints that apply to all instances of the model regardless of how the instances are represented. There shall be no such constraints that are not part of the model specification.
The data model shall be written in such a way that third parties can write specifications defining the process of building instances of the model from data sources other than the two standardized topic map syntaxes.
The data model shall allow implementations to contain more information than what is required by the specification. It shall not allow them to contain less.
The data model shall contain no redundant information. That is, it shall contain no information that might have been inferred from other parts of the model. (For example, it shall not contain parent properties.)
The data model shall define the nomenclature for the individual components of topic map structures.
The data model shall capture the key constructs of topic maps as first class entities in order to remove any potential ambiguity or room for misinterpretation.

4. Topic map parsing requirements

The requirements that apply to topic map parsing are listed below.

For all sets of input documents which the model does not consider to be in error it shall unambiguously define the data model instance resulting from the parsing.
The foundational model shall define the parsing of XTM 1.0 documents and documents conforming to ISO 13250.
The topic map parsing specifications shall be sufficiently detailed and complete that it is possible to build an extensive suite of conformance test cases. They shall not contain such a suite.
The foundational model shall define the process of serializing instances of the model into the XTM 1.0 syntax.
The foundational model should define the process of serializing instances of the model into the ISO 13250 syntax.

5. Level 0 mapping requirements

These requirements apply to the mapping between the level 1 model and the level 0 model.

The foundational model shall contain a complete and unambiguous mapping from the level 1 model to the level 0 model, explaining how to build instances of the level 0 model from the level 1 model.
The level 1 model shall be fully harmonized with the level 0 model, also with respect to nomenclature.
The foundational model may also contain a mapping from instances of the level 0 model to the level 1 model.

6. Relationship to other standards

The foundational model is a piece in a large puzzle of standards and specifications. These requirements define its role in the larger puzzle.

The foundational model shall be specified as part of the ISO 13250 standard.
The foundational model shall be 100% compatible with every aspect of the implicit data model of XTM 1.0 that is actually defined in the XTM 1.0 specification. This includes annex F.
The foundational model shall not contradict any constraints on the model laid down by XTM 1.0, including those of annex F.
The foundational model shall be 100% compatible with the interpretation of the XTM 1.0 syntax as defined in XTM 1.0, including annex F.
The foundational model shall be able to represent all logically significant aspects of ISO 13250 topic map documents.
The foundational model shall not contradict any constraints on the model laid down by ISO 13250, except in so far as they are contradicted by XTM 1.0. In cases of discrepancy XTM 1.0 shall take precedence.
The foundational model shall be 100% compatible with the interpretation of the ISO 13250 syntax as defined in ISO 13250.
The character set used by the foundational model shall be Unicode. It may be that the foundational model ought to require that strings inside the model be represented in a particular Unicode normalization form, for better string matching.
The parsing model shall be defined in terms of the XML Information Set.
The foundational model shall provide a foundation upon which the TMCL and TMQL standards can be specified.
The foundational model shall provide a foundation upon which standardized APIs for topic map engines may be defined.

7. Non-requirements

The requirements listed in this section are, for various reasons, explicitly not goals for the foundational model.

The data model shall include no aspects of topic maps that are not logically relevant. That is, nothing shall be included solely for the sake of preserving information about the syntactical form of topic map documents.
The foundational model shall not be an API, or contain an API specification, nor shall it require topic map APIs to take a particular form.