[sc34wg3] History (was: Re: Montreal meeting recommendations)

[Mason, James David (MXM)]

Steve articulates something in the passage below (and Lars Marius picks up
on it) that I think is very important for us to keep in mind. We've decided
to move the fundamental technical work on Topic Maps back into SC34/WG3, and
that's important for the future of Topic Maps. But if we don't do a good job
there, somebody else, somewhere else, will do it for us. I'm not too worried
about OASIS. I'd be a lot more worried about something from another quarter,
like an RDF+, supplanting Topic Maps entirely.

I obviously feel a vested interest in SC34. But I also shelled out for an
individual membership in OASIS because I think the two groups can work
together. There's certainly plenty of work to keep the two groups busy
(particularly since the "two groups" are in large measure the same people).

Something that was behind the reluctance of certain parties to change SGML
was an unhealthy competition between SGML and another ISO standard called
ODA (if you don't know what that was, consider yourself lucky). The SGML/ODA
Wars occupied entirely too much of our time and promoted an atmosphere of
paranoia on the parts of several of our members. In the long run, ODA died
and SGML won, but by then the forces that led to XML were already pushing
people out of SC34. The technical effect on SGML was mixed: it brought us
both CONCUR and Architectural Forms. The human effect was much more harmful.
We don't need a Topic Maps War.

I believe the current discussion is good because it's getting some issues
settled, but I worry a bit because I hear echoes of old paranoia in the
participants. 

I think the understanding that both the XTM DTD and the architectural
metaDTD in 13250 are only interchange representations of Topic Maps and not
the definition of Topic Maps is very important. That makes it all the more
important that we get the models right.

We all have our own agendas; many of those probably should remain silent: we
need to trust each other enough to get the work done. Let's just figure out
how to make the models work and what we need to do to make the standard a
better representation of what we understand Topic Maps to be. 

Jim Mason

James David Mason, Ph.D.

Y-12 National Security Complex
Bldg. 9113, M.S. 8208
P.O. Box 2009
Oak Ridge, Tennessee 37831-8208

+1 865 574 6973

Chairman, ISO/IEC JTC1/SC34
http://www.y12.doe.gov/sgml/sc34/ornlsc34oldhome.htm




	My own recollection is that SGML was not changed because certain
persons, with excellent and public-spirited intentions, did everything
possible to prevent it from being changed (except to rectify some bugs, all
of which were minor).  In the end, I guess they overdid it, because the only
way to make the changes that were needed in SGML was for W3C to simply
ignore ISO almost entirely.  The W3C effort therefore necessarily *had* to
change the name of the standard. Nowadays, it's not normally called "SGML";
it's much more widely known as "XML".

	If ISO cannot make an *adaptable* Topic Maps standard, then, in
order to have a Topic Maps standard that really works under future
conditions that we cannot predict, we will have to get (for example) W3C to
do an end-run around ISO, and call the resulting Recommendation (or
whatever) something other than "Topic Maps" -- e.g. "Mapped Subjects".  In
other words, the mass market will not be responsive to the brand "Topic
Maps" (which will be, by then, analogous to the still-unknown brand "SGML").
Instead, the mass market will respond to the brand "Mapped Subjects"
(analogous to the well-known brand "XML").  I sincerely hope it doesn't come
to that.  We would all have to abandon all of our investments in the "Topic
Maps" brand name.  What a waste that would be. Not to mention the fact that
"Topic Maps" is simply and inherently a great brand name (unlike "SGML",
which is an absolutely terrible brand name).