[sc34wg3] Question on TNC / Montreal minutes

[Marc de Graauw]

* Marc
| Allowing merge on/off on basenames or basenamestrings makes it
| tremendously easy to make inconsistent use of scope (as namespace).

* Lars
| Well, that assumes that "namespace"-ness is somehow inherent in the
| particular scope used. I am not at all sure that that is true. If you
| look at a scoping topic or a scope, how can a human decide whether it
| is a "namespace" or not? As far as I can tell, the only way is to look
| at the "uniquenames" attribute, which basically tells you how someone
| used that scope. It seems to me that another person might decide to
| use the same scope without making it a "namespace".

True. Of course in general it would make sense to look at where a Topic Map
comes from before you merge it with your own carefully crafted masterpiece.
Just merging with the TNC on, certainly with obvious names for scoping topics
('city', 'language') is a sure-fire way to disaster.

| I don't, but then I don't have any use cases for allowing us to turn
| this capability on anywhere.

Liar :-)
You told me once you use the TNC for some of your customers.

* Marc
| I have doubts about option 1. This is probably far too inflexible.

* Lars
| Hmmm. It is more flexible than what we have now, in the sense that it
| allows you to choose whether or not to apply the TNC. So if allow
| authors to say "follow XTM 1.0" or "follow XTM 1.0 minus the TNC" is
| not enough, it implies that there's something wrong with XTM 1.0.
| Which of course there is.

All true.

* Lars
| What is so special about name + scope that we need to put that
| particular merging rule in the core standard, while the others can go
| into TMCL/application space?
|
| The only honest answer to that question is: because it was so in the
| previous versions.

I agree. The only reason to do this only for basenames is we already have it.
But that's a good reason.

| The real problem here is that we are trying to solve the right problem
| (how to do merging based on topic characteristics) in the wrong place
| (the core standard) while looking at only a fraction of the real
| problem (base name + scope).

I would just keep the TNC (made optional), that's the easy way. But the only
thing I think would be wrong is drop the TNC from the SAM without
simultaneously having the possibility to reapply it (through TMCL). But sure,
TMCL should support more than just basename+scope merging.

| Backwards compatibility is definitely an issue, but I've started to
| realize that it affects us less than we think. The problem arises when
| you have (a) a topic map that relies on the TNC and (b) a topic map
| implementation which is not going to apply it.
|
| If you have a tool that can read in a topic map and export a version
| of the topic map where TNC mergings have been applied, the problem
| goes away. Just preprocess your topic map before you use it.

Smart thinking. (It could become a selling point for TM vendors who have the
preprocessor built into their engine :-))

Marc