[sc34wg3] Re: Backwards Compatability WAS: Public Interest and ISO WAS: [topicmapmail] <mergeMap> questions

[Lars Marius Garshol]

* Lars Marius Garshol
|
| There's a world of difference between issues and changes. Anyone
| should feel free to raise issues at any time. It's the adoption of
| changes that is controversial.

* Sam Hunting
| 
| 1. My reading of Murray's posting -- that is, the posting to which
| the material you excerpt responds -- is that he (unlike, apparently,
| you) was concerned with raising issues.

You're applying your usual creative reading of text, then. That
posting does not contain the word "issue", nor does it contain the
word "question". All Murray discusses is stability and change.
 
| 2. It seems strange to be able to raise problems, but then not be
| able to address them.

Why? What was done about RANK and DATATAG in SGML? Furthermore, nobody
said that we shouldn't address these issues. What we said was that we
shouldn't change the basic model now.

I see no problem in collecting a list of issues and recommendations for
how to deal with then. At some point in the future, when we have
experience with the model and a strong user community, then we can sit
down and make adjustments. We can not do this every single time we
discover a problem.
 
* Lars Marius Garshol
|
| We have a specification (XTM 1.0), that specification is very clear
| on what should be done in the particular case under discussion, some
| people propose that a new specification should contradict it.
 
* Sam Hunting
|
| 1. The "we" we are concerned with on this list is ISO. I take it
| that you plan to propose to have ISO adopt the text of XTM 1.0 as
| is?

The foundational model being developed by ISO is, as you know very
well, intended to unify ISO 13250 and XTM 1.0. ISO has already
accepted as a starting point for a requirements document for this
model a document that says backwards compatibility with XTM 1.0 is an
absolute requirement.

<URL: http://www.y12.doe.gov/sgml/sc34/document/0240.htm >

* Lars Marius Garshol
|
| It is a fact that this will require just about every piece of topic 
| map software there is to change.
 
* Sam Hunting
|
| Well, I accept that this is your strongly held view. 

Hello? It is a fact. If you or anyone else have evidence to the
contrary, please submit it. If you do not, please refrain from
undermining statements in ways that you are not prepared to defend.

This is an extremely important point that I have been exhorting this
community to pay appropriate attention to for the past year and a
half, and to see you wave it aside like this is not something I can
let pass.

| Without having balanced that cost against (say) benefits to
| information owners, 

This is another fact that members of this community seem completely
unwilling to face: many of the major investments in topic maps at this
point are not investments in data, but in software. (It is unlikely to
be any different in the future.) That is, many people who use topic
maps use them to build software on top of topic map engines.

Changing the model means breaking this software. Furthermore, it means
that the people who used this software to create topic maps must
upgrade their databases and upgrade their software.

Software is not just being developed by the vendors, but also by the
users. 

| the public interest, and so forth, it's hard to know how the change
| would net out for the "community" eh?

It seems to me pretty obvious that what the community and the public
needs at this point is stability.
 
| I understand and respect that you have a fiduciary responsibility to
| your firm, but that doesn't mean that everyone in the world shares
| that responsibility, does it?

This is a severe insult, do you realize that? You are suggesting that
in my capacity as a standards developer I am letting my own short-term
financial interests override arguments of technical merit. I expect
that you either substantiate your accusation or apologize for it.

We've already had one blow-out over this, and I find it unbelievable
that you find it necessary to provoke another for no good reason.
This slander and malicious misrepresentation of my motives has to come
to an end. One or more people have been spreading poison like this in
the form of rumours for a long time, and in a sense it's good to see
this finally emerge into the daylight where it can be dealt with.

It is unbelievably infuriating to find that at every step I take to
try and put this standard on a firm footing I am hampered by the same
refrain "he's only thinking about his company". The state of this
standard has been driving me absolutely crazy for the past year and a
half, and to constantly find people obstructing this work through
slander and misrepresentation of my motives is so infuriating that
words completely fail me.

THIS IS NOT ABOUT ONTOPIA! CAN YOU UNDERSTAND THAT?

My concern is the stability of the standard, and the viability of the
community around it. Apparently Murray Altheim is of the same opinion.
How come you're not accusing him of sinister motives? Apparently Kal
is also of the same opinion. Why are you not accusing Kal of thinking
with his purse?

Changing the topic map model is damaging for the topic map community.
If you can't accept that, at the very least accept that as my opinion
and the basis for my actions.

If you stop to think about this, you'll realize that this is just as
bad for Empolis and Mondeca, and their customers, as it is for us and
our customers. The issues are precisely the same. Empolis, for
example[1], has made a deal with a company called Bravo, which
develops some kind of software that generates topic map. This
software, of course, uses the K42 APIs, and what you propose will
require Empolis to go to Bravo and say "Hey, you must change your
software, because we're updating our APIs. You'll also have to upgrade
all your persistently stored topic maps." They will of course have to
do the same thing with all their other customers.

This is acceptable if it is done once, or maybe twice, over a period
of several years, but it can't be done willy-nilly like you seem to
think. When done, it should also be informed by user experience.

| Oh? Say -- just as a hypothesis! -- that after discussion "we" agree
| that the change nets out in a positive way, but it's reasonable to
| wait for a later phase of developing the standard. That's stability
| -- the cart's in motion toward a goal.

This is not acceptable to me. Either we say now "compatibility with
XTM 1.0 is an absolute requirement", or we make it clear that it is
not. If we say that compatibility is an absolute requirement we should
make careful note of anything we consider to be issues with the model.

Later, when we have experience with the standard and a less fragile
community of users, we can make a number of considered changes all at
the same time. That I would call stability.

--Lars M.

[1] I'm writing from recollection, and may not have gotten the details
    entirely correct. Anyone who knows better, please correct me.