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

["Thomas B. Passin" <tpassin@comcast.net>]

[Lars Marius Garshol]
>
> * W. Eliot Kimber
> |
> | 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.
>

d'accord

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

Hmm, then maybe we should not be using xlink?  I think your reasoning is
good, but xlink does specifically use xpointer references.  From section 5.4
of the Xlink Rec:

"For locators into XML resources, the format of the fragment identifier (if
any) used within the URI reference is specified by the XPointer
specification [XPTR]."

I don't know if it is OK to use just part of the xlink Rec.  What do you
think?

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

Me too, it seems most sensible.

Cheers,

Tom P