[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [topicmaps-comment] mergeMap Pointing to More Than OnetopicMapElement
[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC