[sc34wg3] a new name for the Reference Model

Mason, James David (MXM) sc34wg3@isotopicmaps.org
Thu, 2 Jan 2003 09:42:29 -0500


Something else to think about when we play with names: We're writing
standards. Do the names we give to standards say anything about what
conforms to them? 

What conforms to what is still labelled the RM? What does conformance to it
mean? Likewise for what's still called SAM? Where does conformance to one of
those say about conformance to what's currently out there as ISO/IEC 13250?

I just took a quick (< 10 minute!) skim through the RM and came away
wondering about conformance. I found lots of really important, valuable
information about TMs, but I also found myself wondering again whether this
is a standard or a technical report. Although much of the language is about
"must", which is standards-like, there is also "should" language, "may"
language, "may or may not" language, and discussion about what developers of
TMs need to think about, all of which sounds like a TR. Does this document
specify or interpret? 

And this leads me back to a discussion in Baltimore about whether we need a
multipart standard or multiple standards. If we have a multipart standard, I
think it's easier to justify the RM as the much-needed explanation of what
the current 13250 means, whether it turns out to be standard-like or
TR-like. If it's going to be a separate standard, then we have to make it a
standard and be clear about what conforms to it. (If it's an abstract model
of data or data aggregation or something like that and all that really
conforms to it is 13250 itself, then it shouldn't be a separate standard or
even a separate document but rather a part of a revised 13250.) Certainly
it's possible to have a model as a separate document (think of RDF), but the
usual way is to have it as a part (think of STEP or the old OSI). But we
don't want to proliferate parts (think again of STEP, ISO 10303, which has
placeholders for >150 parts and has to have special conventions for
numbering them).

Another way of asking the question about what sorts of documents the RM and
SAM are is to ask who the audience is. Are we writing these things for code
writers or end users? That is to say, are we specifying the actions of a TM
engine and the interchange formats for TM data, or are we marketing
TMs/trying to help people who want to create TMs? At the moment, those two
audiences are sometimes almost the same (that is to say, ourselves), but
what about 5 years down the road? We need the information in both the RM and
the SAM, but we need to understand how we need it.

This is, of course, not a new problem. We had the same problem with SGML, so
ISO 8879 contains a lot of marketing, explanation, and examples. When XML
came along, all that stuff could be dropped, resulting in a lot shorter
standard. (Of course, some other things got cleaned up/dropped, too.)

Having good names for marketing reasons is important, but it's also
important to understand how everything fits together.

Jim