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

[Kal Ahmed]

At 15:37 18/10/2001 -0400, Patrick Durusau wrote:
>Kal,
>
> > >
> > >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 ?
>
>I don't recall advocating that the standard be changed, just pointing
>out cases where multiple scope situations could arise. How that is
>handled, i.e., by implementations or a later version of the standard is
>up for discussion.
>
>It may well be the case that implementors will hit the wall on multiple
>scopes (in a web context?) sooner than theoreticians and their
>experience and methods for dealing with that situation may form the
>basis for some later edition of the standard.

I agree.

When the wall is hit, I do hope that we will all hear about it. If we don't 
it will be because there was no critical mass achieved for topic maps and 
the fact that something is not do-able in topic maps is a specialist, 
minority concern.

*When* the wall is hit is precisely the time that a standards body should 
look at the problem and the existing solutions (if any) and take whatever 
corrective action is necessary.

> > >
> > >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.
> >
>
>The charge of a lack of robustness was inappropriate. It would be more
>accurate to say I would prefer that on finding more than one scope on an
>association that I as a topic map author be given the opportunity to
>specify the result.

That would be a nice feature for a topic map processor to provide, I agree. 
I would like to be able to say choose from:
1) combine the themes into a single scope
2) create two separate associations, one with scope A and one with scope B
3) undo this merge operation

These could all be supported within the framework of the existing standard 
and specification.

><snip>
> > > >
> > >
> > >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 ?
>
>A standards committee could take that option or at the very least wait
>until several solutions and extensive analysis of the problem has
>appeared before attempting to address the issue in a revision.

I would agree. I would also state (IMHO again...<sigh/>) that as far as 
this issue is concerned, we are not at that point yet. We have a 
theoretical problem (please excuse me if this is a problem with a 
real-world example - I have not seen one posted) and a possible 
solution.  If we tinker at the edges all the time, no one will use topic 
maps and we will never get a real-world example.

><snip>
> > >
> > >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.
> >
>
>I don't mind the separation of "legal" and "technical" issues in
>conversation but the older I get the less I see the distinctions between
>legal, religious, philosophical and technical issues. Java syntax is
>admittedly a technical topic but delve deep enough into language design
>and you wander into all sorts of non-technical (at least in the computer
>programming sense) areas of discussion. ;-) (And no, I don't want to
>start a separate thread on that topic!)

Hey - anyone want to discuss vi vs. emacs for topic map editing ? ;-)

Cheers,

Kal