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: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 |
Topic map foundational model requirements
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.