[sc34wg3] Some general comments on the RM (branching from the thread Re: [s c34wg3] The Norwegian National Body position on ISO 13250)

Mason, James David (MXM) sc34wg3@isotopicmaps.org
Tue, 15 Apr 2003 16:37:38 -0400


I'm generally pleased that the RM and SAM crews have been coming to some
understandings since yesterday. I've certainly benefitted from the
discussion.

I'm sorry that I don't have a lot of time to do a detailed analysis of the
RM because I have only a few days left in the office before I leave for
England. However I want to make some general observations.

I observed somewhere in my comments yesterday that I think the point of
standardization is to support the interchange of information and
interoperation of applications. I also observed that we can't achieve that
for TMs just through syntax; we have to define the semantics of the things
that syntax encodes. The SAM is clearly closer to syntax than the RM; from
the SAM we jump off into serialization/deserialization. 

I observed that I felt that the RM was the place for fundemental semantic
grounding for TMs. At this point, the RM is still heavily syntactic. It
places a lot of emphasis on properties (Clause 3) and constraints (Clause
4). This material, particularly in Clause 4, is syntactic, though at a very
abstract level. Perhaps I should say it's structural, but for me the listing
of properties comes closer to syntax than just structure. That syntactic
material is necessary to provide a basis for mapping to the SAM. But it's
severly lacking when it comes to defining the semantics of TMs.

In short: You need to be standardizing both syntax and semantics; at this
point you're neglecting semantics. Syntax/structure should be defined as
concisely as possible, preferably through notation or tables rather than
prose. Prose should be reserved for things that can't be done in notation,
which means semantics.


1. Clause 2, the glossary, should be as brief as possible. Don't try to do
normative stuff here; make it just a collecting point for things that need
to be defined for clarity or because they come up again and again in the
standard. 2.15, "r-topic" is a good candidate to stay in. 2.37 "TMM" has no
business in the standard. Definitions like 2.10, that simply expand an
initialism or acronym, belong somewhere else, either in a list of
initialisms or simply folded back into the primary topics.

2. Clauses 3 and 4 are generally OK, so long as they are dealing with things
that can be dealt with in narrative prose. Reducing the definition of
properties to a table, as in 4.2.1 is good. No sense in wasting words on
that sort of thing. 

Section 4.2.2 should be done likewise: almost all the constraints could be
handled in a table, perhaps by expanding column 6 of Table 4.2.1. All that
should be left of 4.2.2 is the explanatory matter that conveys semantics, as
opposed to structure constraints. For example, the first sentence of
4.2.2.1.1 is OK; the rest of 4.2.2.1 should go into the table. There is
currently no real text in 4.2.2.2, except in the notes, so this whole
section could be reduced to a row in a table. If the stuff in notes 10 and
11 is normative explanation, it shouldn't be in notes.

Figure 1 (note 13) shouldn't be in a note. It should be pulled up into the
main text. If the figure is normative, then it can replace a whopping lot of
inefficient prose.

3. Try to avoid having more than 4 levels of headings.

4. It's fine if we put up an HTML version of this thing with plenty of
hyperlinks. Eliot's HtTime is a good model for that. But that stuff can't be
normative, and it shouldn't be in the printed version. It shouldn't be in
the PDF either, unless you can make the hyperlinks work (which they don't in
the file I pulled down from Sara's site).


Jim Mason