Re: [topicmaps-comment] mergeMap Pointing to More Than OnetopicMapElement

[Lars Marius Garshol <larsga@garshol.priv.no>]

* W. Eliot Kimber
| 
| The XTM 1.0 specification clearly allows documents whose root
| element is not topicMap to be conforming topic map documents *as
| long as* any included topicMap elements do not themselves contain
| elements from another namespace:

That is of course correct, and we have implemented it this way. Our
XTM reader returns a collection of topic maps, which usually contains
a single topic map, but may well contain multiple ones, precisely
because XTM so clearly says that this is allowed and expected.
 
| I don't see how interchange can in any way be impaired by allowing
| this--given the no-foreign-elements-within-XTM constraint there can
| be no confusion about what is XTM data and what is not in a given
| document.

I think Bernard had overlooked that XTM explicitly allowed this, and
was saying that if you don't follow the spec you should expect poor
interoperability. But he can speak for himself.
 
| I am using non-XTM wrapper elements in an experiment I am conducting
| [...]

I think it is quite clear that there are several different possible
uses for embedding XTM data in other XML data.

| The basic hypothesis of this experiment is that if you are going to
| use topic maps as the primary representation of your ontological
| data you might as well author in XTM syntax--saves the trouble of
| defining your own and maintaining transforms and in out of it.
| Anyway, I'm happy with it so far.

I took the other road, and have been very happy with that. Oh well. :)
 
| From my master topic map I then use mergeMap like so:
| 
| <topicMap xmlns="http://www.topicmaps.org/xtm/1.0/";   
| xmlns:xlink="http://www.w3.org/1999/xlink";
|    xmlns:tmc="http://www.isogen.com/xtm/topic_map_control/";   
| xmlns:xi="http://www.w3.org/2001/XInclude";
|    xmlns:xhtml="http://www.w3.org/TR/xhtml";>
| <mergeMap xlink:href="test-map-01.xtm#topic-set-01"/>
| <mergeMap xlink:href="test-map-01.xtm#topic-set-02"/>
| </topicMap>

Hmmm. It would then seem that my original suggestion will work for
your use case, without screwing up existing data in any way:

| I think the spec should amended to say that if you refer to a
| resource using a URI with no fragment you are merging in all the
| topics and associations given in that resource, regardless of how
| many <topicMap> elements occur in the document.
| 
| If there is a fragment, however, it should be a reportable error if
| there is no corresponding <topicMap> element. If there is such an
| element, only the content of that element should be merged into the
| master topic map.

Does anyone disagree with this? If not, we will use it in the first
draft of the new XTM syntax specification.
 
| In this example, the current constraint on mergeMap that it address a
| single topicMap is obeyed, but I could just as easily do:
| 
| <mergeMap xlink:href="test-map-01.xtm#//topicMap"/>

Uh, yes. I have noted this as an issue with XTM, but personally I
think that we should *not* allow XPointer expressions in <topicRef/>
and <mergeMap/> references.

The rationale is that without creating a DOM from the input document
it is very difficult to support XPointer resolution, and building a
DOM is not a good idea from a performance and scaling point of view.

(I have XTM files that run to tens and hundreds of MBs in compressed
form, and we can import them just fine. Doing this via the DOM is,
well, problematic.)
 
| As for scope augmentation, the only reasonable answer would be that
| the applied additional scopes apply to all topics in all topic maps
| merged by a given mergeMap. If that's not what I, as the author
| intend, then I can use multiple mergeMaps. There would be no need to
| complicate mergeMap to do anything different (it would be at least
| as costly as one mergeMap per topicMap).

I agree completely.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >