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

[Lars Marius Garshol]

* Steven R. Newcomb
| 
| Lars Marius indicated that backward compatibility with existing
| implementations was a good reason not to adopt the idea of multiple
| scopes on associations, in the standard model.

I did, and I stand by that.
 
| Level 1: The question of whether multiple scopes on associations
| should be supported is not an issue of backward compatibility,
| because:

This statement is false.
 
|   * There is no stated policy in the standard about what to do about
|     equivalent assertions, so there's no previous provision of the
|     standard to be compatible or incompatible with.
 
Please read sections 2.2.1.6, F.2.4, F.2.5, F.2.6, F.6.2, and F.6.3.

|   * Existing topic maps don't have multiple scopes, but
|     again, *allowing* future topic maps to have
|     assertions that have multiple scopes is not the
|     same thing as *requiring* it.  Existing topic maps
|     would not be invalidated by relaxing the constraint
|     that an association must have exactly one scope.

As far as topic maps represented in syntax form are concerned, this is
true.   As far as topic maps stored in persistent storage are
concered, this is false.  Allowing topic characteristics to have more
than one scope would require all schemas for persistent topic map
storage to change.

|     By definition, backward compatibility is *always*
|     maintained when constraints are *relaxed*.

The proper way to phrase this is that you are changing the model. That
means breaking backward compatibility because we already have
implementations of the model, and we already have software based on
the implementations of the model.

|     Strictly speaking, "backward compatibility" for ISO 13250 has to
|     do with *existing topic maps*, not with *existing
|     implementations.*

When topic map applications are built on top of topic map
implementations it is of no help to them that topic maps that have
been exported into XML form are unaffected if the software that
created these topic maps is broken.

In short, to believe that changes to the model only affects the
vendors is a fallacy. 

|     (Of course, existing implementations are important, too, because
|     it's in the public interest that the public be able to continue
|     to use them.

This is not the issue. The topic map model defines the boundary
between a topic map engine and the software built on top of it, and to
change the model is to break the contract between the engine and the
client software. Some of that software will have been built by the
same people who built the engine, and much of it by others. Changing
the model requires all of it to change.

It seems to be exceedingly difficult for people who don't make
software to understand this, but the plain and simple fact is that
changes to the topic map model are expensive in the extreme. They
cannot be made at whim. 

|     But if they're broken in a way that causes them, under certain
|     cirumstances, to handle topic maps information unreliably,
|     ambiguously, or inaccurately, it hardly seems fair to the public
|     to encourage the idea that they don't need to be fixed.)

It is by no means obvious that the way of representing scope that you
advocate is any way superior to the way it is currently done. To
suggest that current implementations represent this information
unreliably, ambiguously, or inaccurately is quite simply
misinformation.

|   * Allowing assertions to have multiple scopes (in the standard's
|   underlying model -- and there is no such model, currently) would
|   not necessarily invalidate existing implementations.  

Yes, it would. Go look at the javadoc for TM4J. You'll see immediately
that supporting multiple scopes on topic characteristics will require
API changes.

|   It merely provides a way for existing implementations that happen
|   to be broken (either in that they don't merge equivalent
|   assertions, or in that they don't preserve scope information when
|   merging equivalent assertions), to be fixed in a way that will be
|   standardized and will make sense.

Allow me to point out that the currently adopted standard very clearly
states that associations which are equal, but which have different
scopes, should not be merged. Software that does not do this is
therefore standards-compliant, and not in any way broken.
 
| Lars Marius's definition of "backward compatibility" seems to
| suggest that future versions of a standard should reflect the
| *limitations* of existing implementations.  

We already have a standard, and that standard is fairly clear on most
things, but leaves some undefined. I firmly believe we should respect
that standard, which is, after all, a contract between the
standards-makers and the public. I recognize that where it is unclear
we may have to make adjustments, but it does not seem that any changes
need to be made to the model.

| I strongly resist and denounce this formulation of the purpose of
| creating public standards.

You are fighting a strawman, and so it's now wonder that you are
finding it easy to beat the stuffing out of him.

| I believe that the purpose of creating a public standard is to make
| certain technical decisions on behalf of the public at large, 

I agree, but there is a second part: one must stick to those decisions
once they are made.

| not on behalf of just one small segment of the public that happens
| to have an interest in making the standard be exactly as crippled
| and broken as their existing implementations happen to be.

So, you are describing me as a small segment of the public with a
crippled and broken implementation, and a vested interest in making
the standard equally broken?

If so, this is insulting, offensive, and, worst of all, a severe
distortion of the facts. I expect an apology.

The standard (XTM 1.0) is clear on what software should do with
associations with multiple scopes. Ontopia's software conforms to
this, and that is no accident. How this can be construed as a desire
to change the standard is a mystery to me. You are the one who wants
to change the standard.

--Lars M.