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

["W. Eliot Kimber" <eliot@isogen.com>]

Bernard Vatant wrote:
> 
> *Murray Altheim
> 
> > XTM was designed as an interchange language, not a
> > catch-all for all possible "legitimate" topic map expressions.
> > Since there is a simple solution for this within the current
> > specification, I don't see that opening up the specification
> > merely because there *may* be reasons to express something in
> > an alternative (and potentially more problematic) way would be
> > a benefit for anyone.
> 
> I agree with Murray. A DTD is a DTD. You can embed <topicMap> elements, with all their
> XTM-like children, inside any kind of XML doc, and process it the way you like, but be
> prepared to pay the price, that is poor interoperability. It can't be considered XTM
> conformant any more, and you can't ask for XTM processors to make sense of it, nor wait
> for XTM specification to tell you what to do in such a case.

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:

>From 4.4, XTM Document Conformance

    * All of the syntactic and other constraints specified by the XTM
1.0 Specification are honored in each of the <topicMap>  elements
contained in the document. When each <topicMap>  element is processed as
defined and described in Annex F: XTM Processing Requirements, there
must be no Reportable XTM Errors.

Thus Murray's objection is incorrect--it is explicitly conformant to the
XTM spec and all conforming XTM processors should handle the case. 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 am using non-XTM wrapper elements in an experiment I am conducting
with making it easier to author topic maps directly in XTM syntax by
using enclosing structures to organize groups of topics into logical
sets--this has no affect on the interpretation of the topic map (no
ambiguity or potentially confusing non-topic-map stuff is used *within*
the scope of the XTM data) but makes it much easier to author a large
topic map by organizing things in ways that make sense to the author.
Here is a small example:

topic-set-01.xtm:

<?xml version="1.0"/>
<topicSet 
  xmlns CDATA 'http://isogen.com/xtm/topic_map_control'
  xmlns:xtm CDATA #FIXED 'http://www.topicmaps.org/xtm/1.0/'>
<title>ISOGEN-Defined Fundamental Topics</title>
<description>
<para>These topics are used by the automated test cases for the
MergeMapResolver
Java program.</para>
</description>
<topicSet>
<title>Fundamental Characteristic Types</title>
<description>
<para>These topics define fundamental topic characteristic types.</para>
</description>
<xtm:topicMap id="topic-set-01">
<xtm:topic id="typing-topic">
<xtm:instanceOf>
<xtm:subjectIndicatorRef
xlink:href="http://www.topicmaps.org/xtm/core.xtm#class"/>
</xtm:instanceOf>
<xtm:baseName>
<xtm:baseNameString>Typing Topic</xtm:baseNameString>
</xtm:baseName>
<xtm:baseName>
<xtm:baseNameString>Characteristic Type</xtm:baseNameString>
</xtm:baseName>
<xtm:occurrence>
<xtm:instanceOf>
<xtm:topicRef
xlink:href="./ui-topic-types.xtm#definition"/></xtm:instanceOf>
<xtm:resourceData>A topic whose only or primary purpose is to
characterize
topic characteristics by their functional, rather than semantic, role.
Characteristic
types are primarily used to enable specialized user interface and
processor
behavior.</xtm:resourceData>
</xtm:occurrence>
</xtm:topic>
</xtm:topicMap>
</topicSet>
<topicSet>
<title>Fundamental Subjects</title>
<description>
<para>Defines subjects that are universals. Used as top-level
supertypes.</para>
</description>
<xtm:topicMap id="topic-set-02">
<xtm:topic id="abstract-data-type" xmlns="">
<xtm:instanceOf>
<xtm:subjectIndicatorRef
xlink:href="http://www.topicmaps.org/xtm/core.xtm#class"/>
</xtm:instanceOf>
<xtm:baseName>
<xtm:baseNameString>Abstract Data Type</xtm:baseNameString>
</xtm:baseName>
<xtm:occurrence>
<xtm:instanceOf>
<xtm:topicRef
xlink:href="./ui-topic-types.xtm#definition"/></xtm:instanceOf>
<xtm:resourceData>A subject that represents an abstract data type,
as distinct from business objects or characteristic
types.</xtm:resourceData>
</xtm:occurrence>
</xtm:topic>
</xtm:topicMap>
</topicSet>
</topicSet>

I haven't done extensive authoring yet, and I haven't written any
support functioins for my XML editor, but so far I've found it as easy
to edit topic maps in this way as it is to edit any other comparable
syntax for capturing the same sort of information--while one could
define slightly less verbose syntaxes for some characteristics, the XTM
syntax isn't that bad for verbosity--certainly no worse than most
technical documentation DTD's I've worked with. And a few editor
customizations will make things much easier. 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.

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

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"/>

At least within the context of the DOM-based processing that I'm doing
in my mergeMap resolver there's no implementation difficulty in handling
this case and I don't see that there can be any ambiguity about it--it's
identical to having multiple mergeMap elements, one for each topic
map--just more convenient.  I wouldn't fight too hard for allowing
multiple result topicMap elements but I can't see any reason to impose
the constraint.

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

My mergeMap code already enforces the requirement that mergeMap point to
topicMap elements exclusively.

Cheers,

E.
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139