[sc34wg3] The Norwegian National Body position on ISO 13250

Mason, James David (MXM) sc34wg3@isotopicmaps.org
Mon, 14 Apr 2003 14:12:13 -0400

WG3 Crew:

I have been out of the loop for a couple of weeks, working on a special
project not related to SC34. I've just started catching up with the =
Now I think it's time to make to the whole list an observation I've =
privately to a couple of you: Observing WG3 at the moment is somewhat =
listening to Strauss's Salom=E9. There are a lot of characters on the =
They're all talking, some of them quite passionately. And they're all
talking past each other, rather than to each other. (To be sure, I'm =
accusing anyone in WG3 of espousing any of the opinions of the =
characters in
that opera, nor am I asking for anyone's head on a platter -- yet.)

But I was disturbed by the degree to which this discussion heated up. I
think we're being too excitable and missing the point of what we're
chartered to do. Some of the people who were getting heated at each =
actually seemed to me, in my perhaps shallow reading, to have started =
close to agreement, but they continued to talk just past each other's =
until they got to the point where they couldn't communicate any more.

I'd like to take Michel's questions (copied below) as a starting point. =
offers two directions for standards development: (1) open, flexible,
responsive to vendor needs, and (2) closed, restrictive, taking an =
punitive view on what's allowed to claim support of Topic maps. I sense =
Michel is inclined more to (1); at least I hope he is because that's =
we're supposed to be doing.=20

SC34, back in the early 80s, was unusual because it was driven mostly =
users, not vendors. It was sort of like an open-source software =
project. Vendor-driven standardization was seen as evil. We had to =
create a
standard and convince people to implement it. However, we're not in the
environment that we faced in 1982, where the vendors were seeking
proprietary solutions. SGML/XML has triumphed, and the vendors are =
interested in how to interchange data. WG3 doesn't have to create the =
Maps software world from scratch, the way the old SC18/WG8 had to =
create the
SGML world. We're only a couple of years into TM time, and we already =
at east three commercial vendors and several open-source products =
TMs. Our job is primarily to create an environment in which more
vendors/software writers can compete, with some secondary emphasis on
encouraging the user community to use TMs so that the vendors will have =
reason to compete.

Steve P got this thread going be remarking that vendors are out there
starting to say they supported TMs when they clearly didn't understand =
they were talking about. We need enough conformance in the standard to
filter out the ones that are misleading customers, but more than that =
need the standard to help the serious vendors interoperate. (This =
reminds me of the SGML world in the mid 80s, when all sorts of things =
claiming to support SGML whether they could really do that or they just =
a canned filter for the CALS DTD.)

I've heard a few people complain that the SAM is oriented too much to
vendors' needs. To that I can only reply, "What's wrong with that?" =
thread has shown that there are people who need interoperability =
that are related to the TMCL/TMQL complex of projects, and that seems =
to be
tied to the SAM. Given the economics of standards development today, we =
to go where the money is. This is what I hear coming not only from =
Steve P
but also from Mary and others.

I've also heard (elsewhere) assertions that "the SAM is not Topic =
Maps." I
am not certain what all that charge implies, nor do I have time to =
it in detail. It is, instead, the obligation of those who make that
assertion to document it. Until they do document it, the assertion is =
not in
and of itself sufficient cause to slow down development of standards

Nonetheless I want to pursue a couple of possibilities related to the

One possibility is that the SAM is not sufficiently clear on some =
points. Last week, someone remarked to me that there's a point related =
uniqueness of topics and the impact on merging that he thought might be
implicit in the SAM but wasn't explicit. If it's a useful idea and the =
can be tweaked, then let's get that on the table. If it's a fix worth =
let's get it done and get on to other work.

Another possibility is that there are whole areas of potential TM
application that the SAM doesn't cover. We obviously can't know all the
things that people will be doing with TMs five years from now. I've =
tried to
do some pretty odd things with TMs myself. Certainly we hadn't thought =
all the things that could be done with SGML in 1981 when I got involved =
even by 1986 when the standard was published. It therefore behooves us =
create solutions that are sufficiently open ended that we don't have to
change them two years from now. But we also can't wait until two years =
now to finish our current projects. If there are glaring holes in the =
if there are obvious areas where the SAM won't work, we need to have =
identified. Otherwise, we need to work with what we know and =
standardize on
that basis.

Something else that came out of Steve P's messages is a reminder that =
not enough to conform to XTM or HyTM. You can make an XML document that
conforms to XTM and is nonetheless nonsense. More seriously, some piece =
software that claims to support TMs might export a file that validated
according to XTM but was useless to another piece of software that =
XTM and claims to support TMs. Correcting this problem is the most =
task before the TM standardization community today.

There is a semantic component to TMs in addition to the syntactic. =
that standard has to provide sufficient semantic specifications to =
interoperability. It does not matter to me where that happens. Although =
quick view of the SAM is oriented towards the syntactic side of TMs, I =
conceive of the semantic side's being there, too.=20

I would have thought, however, that the RM should have been the =
place to extablish that semantic layer. I do not sense that the March =
text of the RM does this in a usable way. Although the March 16 RM =
out a lot of unnecessary verbiage that was in the previous text and
approaches an almost algebraic brevity in places, it still doesn't tell =
WHY I should want any of these constructs or HOW to use them to =
TMs. The RM is itself still a syntactic construct (though at a highly
abstract level), not a semantic one. In other words, it does not =
achieve the
semantic standardization that must complement the existing concrete
syntactic standardization. Almost all of the current content of the RM =
be reduced to a couple of tables and a diagram or so to handle the =
syntax. That would leave sufficient space for useful text for semantic
standardization. If the RM cannot perform the semantic standardization =
what it means to be a TM and what it means to merge TMs, then the SAM =
have little choice other than to become self-sufficient.

One thing the TM standardization program does not need is a purely =
exercise in advanced hypertext. If we can't tie it to the immediate =
of TM interchange and interoperability, then it probably belongs in a =
for Extreme and not in an ISO/IEC standard. JTC1 has already been =
enough by academic standardization: that gave us OSI, MHS, and ODA. =
why there's no longer anything of the original JTC1/SC18, just the =
WGs 8 and 9 that didn't want to be in SC18 in the first place.

We have a little over two weeks before we meet in London. In that time =
need to sort out what's useful, and what's better left for future =
Let's stop talking past each other and start communicating amongst

Jim Mason

James David Mason, Ph.D.

Y-12 National Security Complex
Bldg. 9113, M.S. 8208
P.O. Box 2009
Oak Ridge, TN 37831-8208 U.S.A.
+1 865 574 6973

Chairman, ISO/IEC JTC1/SC34

-----Original Message-----
From: Michel Biezunski [mailto:mb@coolheads.com]
Sent: Saturday, April 12, 2003 11:14 PM
To: sc34wg3@isotopicmaps.org
Subject: RE: [sc34wg3] The Norwegian National Body position on ISO =

Steve Pepper:

>A bigger problem is that new tools are appearing claiming to
>support topic maps. What we see, especially in Norway, is that
>the increased interest for topic maps is leading to the
>development of "topic map" software by people who have not
>participated in the standards process. In itself this is
>obviously very welcome. The trouble is that the lack of
>guidance in ISO 13250 is leading to systems that are severely

Can you please be more specific here? What do you mean
by severely non-conformant? How many such examples do you

We need to study this in very much detail knowing
that there are 2 possible fixes to such a problem:

1) Make the standard hospitable to software currently
   considered non-conformant. The standard needs to
   be apparently more flexible and open.

2) Make the standard close so that it would exclude
   all software which is not strictly conformant to
   whatever the conformance clause will eventually

This is a really important strategic choice to be made.

Please give us all the elements to document the
problem you are mentioning.

Michel  =20
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Web  :http://www.coolheads.com
Voice: (718) 921-0901
sc34wg3 mailing list