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

[Kal Ahmed]

At 14:08 18/10/2001 -0400, Patrick Durusau wrote:
>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.

I think it is right and proper that questions such as this should be 
examined and evaluated, but surely the stability of a specification is at 
least as important as its conformance to a particular world view. If this 
change is made, why would an implementor not see it as the thin end of a 
wedge, throw up their hands and say "I'll just implement it my way because 
these topic map guys can't make up their minds for more than 6 months at a 
stretch." Then where would we be in terms of interop ?

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

TM4J, OKS and Empolis's APIs all parse XTM (one association, one scope) and 
some of them parse ISO 13250:2000 (one association, one scope) and all of 
them have a function such as:

ScopeType Association.getScope()

So yes, they do "die" if you try and give them a topic map with multiple 
scopes on an association - they will refuse your topic map because your 
topic map does not conform to the XTM/ISO interchange syntax definition. 
They do not support multiple scopes an on association in their internal 
data models because neither ISO 13250 nor XTM 1.0 make any provision for 
multiple scopes on an association.

Adding multiple scopes to an association is not, IMHO, a "fix" it is a 
"change".

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

Then why not leave it as a feature for vendors to optionally provide:

AssociationList TopicMap.getAssociationsEquivalentTo(Association assoc)

and leave the specifications alone ? What **interchange** benefit is 
derived from multiple scopes ?

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

Agreed in fact I'd just as soon drop the whole legal side of this thread. 
My sister is the barrister in the family (every family should have one!), 
not me.

Cheers,

Kal