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

[Patrick Durusau]

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.

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

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

<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!)

Looking forward to seeing everyone at the next meeting!

Patrick  


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