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

[Lars Marius Garshol]

* Patrick Durusau
| 
| It looks difficult to me how one would avoid the issue of multiple
| scopes on associations in an implementation. 

It hasn't been avoided, it has just been resolved in a different way
from what SRN would like. As it is now, if you want to repeat an
association in multiple scopes you can just do so. It will not be
merged into a single association, but will stay as separate
associations with different scopes.

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

Every implementor is doing the same: representing the association
multiple times. XTM 1.0 is very clear on how this should be handled,
if you read F.2.4. Not everyone is agreed that there is any problem
with that.
 
| 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.

The issue is not just this one, there are many more things that might
be changed in the XTM 1.0 model, just as there will be in any model.
We cannot make this change without considering the other issues that
have been raised (most of them by PMTM4), nor can we do so without
giving fair warning to all topic map implementors and users that we
are about to change topic maps under their feet.
 
| 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.

This is in the nature of current programming languages, I'm afraid.
If your topic map engine has a class representing associations, that
class must somehow give client software access to the scope of the
association. This will be done in different ways when the scope is a set
of topics from when it is a set of sets of topics.

It seems to me that this is something that people in the topic map
community consistently do not understand: the standard is about the
model, the syntax is just a mechanism for exchanging instances of the
model. Changes to the syntax are cheap, while changes to the model are
enormously costly.

I've explained this successfully before, so I'll repeat that
explanation here.

  Any non-trivial piece of software uses interfaces to separate the
  various modules it consists of from one another. The good thing
  about this is enables abstraction to be used as a scalpel to cut a
  huge, unmanageable project into manageable pieces.

  This scalpel is double-edged, however, because it makes the software
  on both sides of the interface depend on the interface. If the
  interface is very abstract it can be used throughout many different
  parts of the software, which makes the software consistent, easier
  to learn, reduces the amount of code, and enables code reuse, but at
  the same time it causes large parts of the software to depend on
  this highly reused interface.  If you change the interface you have
  to change all the pieces of code that use it.

  A plausible generalization of XML might be to remove the artificial
  distinction between attributes and elements. If you did this it
  would mean that the DOM interface would have to change quite
  dramatically in order to support this generalization. If you change
  the DOM radically it means that every DOM, XPath, XSLT, and XQuery
  implementation that uses it also has to change. Lots of packages
  like dom4j, JDOM, XML editors, web publishing tools, XML generation
  tools, validators, document comparison tools, document databases,
  and so on and so forth also have to change. (Even TM4J would have
  had to change.)

  It is very much the same with topic maps and the topic map model.
  If we radically change the model it means that we have to change
  every topic map engine, and every piece of software built on those
  engines.  That is a huge cost, and one that will have to be paid by
  the vendors, their customers, the open source developers, and
  everyone who's done work with the open source tools.

  If this discussion seems a bit vague the best thing you can do is
  probably to download TM4J and look at its javadoc. That should show
  you what the interfaces I am talking about look like, even if you
  may not be a Java programmer. tmproc, TM4J, K42, and the Ontopia
  Engine all have different interfaces, but they are roughly at the
  same level of abstraction, so this discussion applies equally to all
  of them.

  This doesn't mean that we should never change the model. Please
  don't think that that's what I'm saying. It just means that we
  should be very careful when we do it, and that we should take care
  not to do it any more often than what is absolutely necessary.
  There will be times when we have to, and I am resigned to that, but
  let us be careful, and let us make these changes knowing what their
  costs are.

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

It is not the case that current implementations cannot handle this.
What has happened is that some individuals have expressed the opinion
that they should handle this in a different way from what they
currently do.

| It is not necessary that one vendor capture every capability of
| topic maps in a single application.

It is absolutely necessary that every topic map implementation capture
every aspect of the topic map model (and this is one of them) or else
entirely refrain from claiming conformance with the standard. If not,
there is no point in having a standard.
 
--Lars M.