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