[sc34wg3] Requirements for the foundational model - level 1
Lars Marius Garshol
sc34wg3@isotopicmaps.org
Mon, 29 Oct 2001 23:39:31 +0100
This is a multi-part message in MIME format.
--------------040707030904080001030208
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi everyone,
Here are Graham's and my requirements for the foundational model for
topic maps, level 1. These requirements are intended as starting points
for discussion, not as executive decisions, so please do let us know what
your views on these requirements are.
Sara, could you put this into the SC34 document archive, please? Thanks!
--Lars M.
--------------040707030904080001030208
Content-Type: text/html;
name="proposed-requirements.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="proposed-requirements.html"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<title>Topic map foundational model requirements</title>
<style type="text/css">
th {
text-align: left;
vertical-align: top;
}
h1, h2, h3, h4 {
font-family: Verdana, Helvetica, sans-serif;
}
body {
margin-left: 10%;
margin-right: 10%;
margin-top: 48pt;
}
dt {
font-weight: bold;
}
</style>
</head>
<body>
<h1>Topic map foundational model requirements</h1>
<table>
<tr><th>Version:<td>0.1.0
<tr><th>Date: <td>2001-10-29
<tr><th>Editor: <td><a href="mailto:gdm@empolis.com">Graham Moore</a>,
<a href="http://www.empolis.com">Empolis</a>
<tr><th>Editor: <td><a href="mailto:larsga@ontopia.net">Lars Marius
Garshol</a>, <a href="http://www.ontopia.net">Ontopia</a>
</table>
<p>
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 <a
href="http://www.y12.doe.gov/sgml/sc34/document/0240.htm">so-called</a>
level 1 model, leaving the requirements on the level 0 model to the
editors of that model.
</p>
<p>
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
<a href="http://www.infoloom.com/mailman/listinfo/topicmapmail">the
topicmapmail list</a>. National bodies may wish to send their comments
via the ISO secretariat.
</p>
<h2>1. Terminology</h2>
<p>
The following topic map terms will be used in this document as defined
here.
</p>
<dl>
<dt>topic map processing</dt>
<dd>The processing of topic map information by software in any way for
any purpose whatsoever.</dd>
<dt>topic map parsing</dt>
<dd>The process of building some program-internal representation of a
topic map from a topic map serialized in some format.</dd>
</dl>
<p>
Throughout this document the following key words are used to indicate
the extent to which the editors consider themselves bound by each
requirement.
</p>
<dl>
<dt>shall</dt>
<dd>Means that the requirement is absolute.</dd>
<dt>should</dt>
<dd>Means that the requirement is a goal.</dd>
<dt>may</dt>
<dd>Means that the requirement is considered important, but that it is
not yet clear whether the data model should conform to it or not.</dd>
</dl>
<h2>2. General requirements</h2>
<p>
The main requirements on the foundational model are listed below.
</p>
<ol>
<li>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.</li>
<li>The foundational model specification shall not unduly constrain the
internal aspects of topic map implementations.</li>
<li>The foundational model shall not be limited to a web environment
or a HyTime environment, but shall work within both.</li>
<li>The text of the foundational model specification shall be as
readable and concise as precision will allow.</li>
<li>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.</li>
<li>The foundational model may contain prose explaining the semantics
of data model instances.</li>
</ol>
<h2>3. Data model requirements</h2>
<p>
The requirements on the data model part of the foundational model are
described below.
</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.)</li>
<li>The data model shall define the nomenclature for the individual
components of topic map structures.</li>
<li>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.</li>
</ol>
<h2>4. Topic map parsing requirements</h2>
<p>
The requirements that apply to topic map parsing are listed below.
</p>
<ol>
<li>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.</li>
<li>The foundational model shall define the parsing of XTM 1.0
documents and documents conforming to ISO 13250.</li>
<li>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.</li>
<li>The foundational model shall define the process of serializing
instances of the model into the XTM 1.0 syntax.</li>
<li>The foundational model should define the process of serializing
instances of the model into the ISO 13250 syntax.</li>
</ol>
<h2>5. Level 0 mapping requirements</h2>
<p>
These requirements apply to the mapping between the level 1 model and
the level 0 model.
</p>
<ol>
<li>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.</li>
<li>The level 1 model shall be fully harmonized with the level 0
model, also with respect to nomenclature.</li>
<li>The foundational model may also contain a mapping from instances
of the level 0 model to the level 1 model.</li>
</ol>
<h2>6. Relationship to other standards</h2>
<p>
The foundational model is a piece in a large puzzle of standards and
specifications. These requirements define its role in the larger
puzzle.
</p>
<ol>
<li>The foundational model shall be specified as part of the ISO 13250
standard.</li>
<li>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.</li>
<li>The foundational model shall not contradict any constraints on the
model laid down by XTM 1.0, including those of annex F.</li>
<li>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.</li>
<li>The foundational model shall be able to represent all logically
significant aspects of ISO 13250 topic map documents.</li>
<li>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.</li>
<li>The foundational model shall be 100% compatible with the
interpretation of the ISO 13250 syntax as defined in ISO 13250.</li>
<li>The character set used by the foundational model shall be <a
href="http://www.unicode.org">Unicode</a>. 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.</li>
<li>The parsing model shall be defined in terms of the
<a href="http://www.w3.org/TR/xml-infoset">XML Information Set</a>.
<li>The foundational model shall provide a foundation upon which the
TMCL and TMQL standards can be specified.</li>
<li>The foundational model shall provide a foundation upon which
standardized APIs for topic map engines may be defined.</li>
</ol>
<h2>7. Non-requirements</h2>
<p>
The requirements listed in this section are, for various reasons,
explicitly not goals for the foundational model.
</p>
<ol>
<li>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.</li>
<li>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.</li>
</ol>
</body>
</html>
--------------040707030904080001030208--