OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] mergeMap Pointing to More Than One topicMapElement



* Lars Marius Garshol
|
| 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.

* Bernard Vatant
| 
| But that means you will attach the same <scope> elements to all
| those characteristics, right? 

Provided whoever created the master topic map put in any added themes
on the <mergeMap>, yes. Otherwise no scopes will be added at all.

| It figures the merged map does will not be able to keep track of the
| various source <topicMap> elements.

That is correct. If the author wanted to do that the author should
have created multiple <mergeMap> elements, each referring to a
different <topicMap> element in the merged-in resource. (You should
probably read my second paragraph one more time.)

It may also be that we would prefer a different way of keeping track
of this information.

| This could raise some issues and has to be well thought about.

I've already noted it as an issue for the new XTM syntax specification.
Probably the first version of the text will say whatever emerges as
the consensus in this discussion, and then people can comment on it if
they feel there is anything wrong. 

* Lars Marius Garshol
|
| 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.
 
* Bernard Vatant
|
| Agreed. But maybe it could happen that there are *several*
| <topicMap> elements in this fragment? 

Good point. It may be that we should make it an error if the
fragment identifier[1] does not refer to a <topicMap> element.
In any case, the author controls what the fragment identifier refers
to, so the author could point to the desired <topicMap> element.

| Although allowing several <topicMap> elements as children in a
| larger DTD seems quite a weird concept to me ... but weird DTDs do
| exist :))

I think there might be legitimate reasons for doing such things, and
it would in any case be poor specification design if we disallowed
something we weren't absolutely sure would be an error.

[1] The fragment identifier in a URI reference is the bit after the
    '#'.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC