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

[Kal Ahmed]

I've taken the liberty of renaming this thread (again!) in an attempt to 
separate the technical from the (interesting) legal ;-)

At 15:52 17/10/2001 -0500, Steven R. Newcomb wrote:
>[Sam Hunting:]
> > [steve newcomb]
> > > It seems to me that this very technical issue is
> > > clearly a public interest issue, and I'm very glad to
> > > have an occasion, finally, in this note, to explain why
> > > that is so.
>
> > And by "public interest" we mean? (On a postcard,
> > please -- so I can understand it.)
>
>OK, here's my postcard.

[ postcard removed ]

>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 take extremely serious exception to his remark on two
>levels.
>
>Level 1: The question of whether multiple scopes on
>associations should be supported is not an issue of
>backward compatibility, because:
>
>   * 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.

I think that there is a policy in XTM, though it is not immediately clear.

Firstly, XTM says this about associations:

2.2.4 Association
An association is a relationship between one or more topics, each of
which plays a role as a member of that association. The roles a topic
plays in associations are among the characteristics that can be
assigned to it and are therefore governed by scope. Each individual 
association is an instance
of a single class of association (also known as an association
type) that may or may not be indicated explicitly. The default
association type is defined by the "association" published subject.

and says this about scope:

2.2.1.6 Scope
Scope specifies the extent of the validity of a topic characteristic 
assignment. It
establishes the context in which a name or an occurrence is assigned to a
given topic, and the context in which topics are related through
associations. Every characteristic has a scope, which may be specified
either explicitly, as a set of topics, or implicitly, in which case it is 
known as the unconstrained scope. Assignments made in the
unconstrained scope are always valid.

Note that 2.2.1.6 says "Every characteristic has *a* scope". To me that 
says that a role played by a topic in an association has one and only one 
scope. So adding multiple scopes to an association would break 
"compatibility" with XTM 1.0 unless there is some way to map multiple 
scopes in the processing model into a single scope.

>   * 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.
>     By definition, backward compatibility is *always*
>     maintained when constraints are *relaxed*.
>     Backward compatibility problems only occur when new
>     constraints are *added*.  Remember: the ISO 13250
>     standard is a standard for interchangeable topic
>     maps, and what they mean.  Strictly speaking,
>     "backward compatibility" for ISO 13250 has to do
>     with *existing topic maps*, not with *existing
>     implementations.* (Of course, existing
>     implementations are important, too, because it's in
>     the public interest that the public be able to
>     continue to use them.  It's always a balancing act.
>     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.)

Two things:

1) Calling this a "relaxation" is both accurate in one sense and a little 
misleading in another important sense. Allowing multiple scopes to appear 
in topic maps *requires* conformant applications to support multiple 
scopes. Your "relaxation" of a constraint actually imposes a new constraint 
on implementations. Yes, existing topic map data would be compatible and 
that is extremely important, but existing applications would have to be 
changed...again.

2) Leading on from this, it is not fair to downplay the role of 
implementations in the success of topic maps or to somehow suggest that 
implementations are not "in the public interest". Indeed, in my own 
research for my paper for XML 2001 a large proportion of the people I 
talked to felt that the lack of commercial tools was a major hurdle in 
getting topic maps adopted and accepted.

It is only human to err...and just as human to want to un-err, but if the 
models that we develop in trying to fix what we perceive to be problems 
cause the topic map application developers to have to return to their 
designs every time a new expression of the "true topic map model" is worked 
out, we are never going to have a topic map industry that gets past 1.0 
releases...and users are not going to buy in to topic map technology.

>   * 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.  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.


>Level 2: As you say, Sam, the question of what will
>best serve the public interest, and, indeed, what *is*
>the public interest, is deeply intertwingled with every
>design decision regarding a public standard.  When any
>participant has some other perceived basis for making a
>technical decision about a public standard, it's
>important that we all understand exactly what that
>basis is.

I promised not to get into legal arguments, but this one was sitting here 
in the middle of  the technical stuff, so my apologies. IMHO, "public 
interest" is a weasel word - I don't know what is in the public interest, 
and I don't think that anyone can know what best serves the public 
interest. We can all dress up our arguments both for and against a design 
decision as being "in the public interest". Every participant in a 
standards making process has a reason to be involved - all opinions are 
important and none should be promoted as being "the public interest".

>Lars Marius's definition of "backward compatibility"
>seems to suggest that future versions of a standard
>should reflect the *limitations* of existing
>implementations.  I strongly resist and denounce this
>formulation of the purpose of creating public
>standards.  I believe that the purpose of creating a
>public standard is to make certain technical decisions
>on behalf of the public at large, 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.  When private interests use public processes for
>private advantage at unnecessary public expense, we
>normally regard such processes as corrupt.

But we already have a public standard. And we have nascent technical 
implementations of that standard. Do we want to help that baby or throw it 
out with the bath-water ?


>So, I'd like to ask everyone two questions:
>
>(1) If the public interest is *not* the basis on which
>     our design decisions should be made, what, exactly,
>     *should* be the basis on which design decisions are
>     made?

Technical design decisions should be decided by technical argument, not by 
weasel words. Your technical arguments are strong, Steve. Lars Marius 
points out some important practical aspects of that for developers and I 
have attempted to put Lars Marius' concerns into context from the point of 
view of some one who hopes to make a living out of helping paying customers 
to create valuable topic map-based solutions. All three points of view must 
be represented in this discussion, and these (and any others that may come 
up) should be the basis on which the design decision is made.

>(2) Assuming that there is no valid basis other than
>     public benefit for making any particular design
>     decision in a public standard, is there any virtue
>     whatsoever in keeping the standard exactly as
>     limited and/or broken as its existing
>     implementations are?

Is a standard which changes every 12 months a standard ? If a standard is 
widely interpreted in a particular way, shouldn't a standards-making body 
be sensitive to that existing interpretation ?

Cheers,

Kal