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

[Patrick Durusau]

Kal,

OK, I'll avoid the interesting legal stuff in this post. ;-)

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

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

I think you and Steven agree (at least from my reading of your posts)
that the current standard says one association has one scope. (further
citation and argument on that point omitted)

I think Steven's question is whether that was the right choice and could
that be changed in some future standard in a way that is backwards
compatible with current topic maps.

It looks difficult to me how one would avoid the issue of multiple
scopes on associations in an implementation. Within a business or
library system, error checking might be able to enforce the one
association - one scope rule. But in a larger, less structured context
(like the WWW) surely topic map engines are going to confront
intentional or unintentional multiple scopes on topics. It would seem
(at first blush) that it would be better to have some principled way to
deal with those instances rather than every implementor doing "what is
right in their own eyes." 

I don't know that multiple scopes on associations is a much of a feature
or improvement as it is an attempt to seal a hole in present framework.
Perhaps multiple scopes is not the best way to deal with equivalent
assertions but I would prefer that judgment be made after a full
examination of the problem and not simply declaring it off-limits as a
possible solution.

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

Are you suggesting that anyone has built a topic map engine that demands
"one association had one scope" and dies otherwise? Not a very robust
existing application if that is the case.

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

I don't think anyone is downplaying the importance of implementations in
the acceptance of topic maps. For use in a highly structured
environment, a one association - one scope topic map implementation
would work quite well. Multiple scopes are an error condition handled in
the business logic. Sort of like using a Windows 2000 server for a work
group. For a different environment, says merging remote (and
unauthenticated) topic maps, then an engine that resolves multiple
scopes on associations would be a real advantage. It is not necessary
that one vendor capture every capability of topic maps in a single
application. 

<snip>
> 
> 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".
> 

Just as I dropped the notion of "corrupt" from my earlier post I would
suggest that we drop the rhetoric of "weasel word" from this
continuation. 

Without straying too far into the legal stuff, the definition of "public
interest" has been long debated in a variety of contexts. I don't think
anyone would disagree that we all start our discussions from a
particular point of view, situation and interest. That does not mean
that we cannot try to see the longer term implications of our positions
both for ourselves as well as others. 

If I were a font foundary, I would argue loudly for more precomposed
characters in Unicode but should be able to recognize that the fewer
such characters in the standard the easier it will be to write software
for multi-lingual applications. Not to mention that a more widely used
standard (or robust) standard, creates opportunities for me that did not
exist before. I am NOT saying that all of the decisions in the
Unicode/10646 realm were "in the public interest" or even ones that I
personally agree with. I am saying that it is possible to make the
attempt at judging issues while being mindful of personal interests that
could be influencing our view of the world. 

Patrick 

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu