[topicmapmail] <mergeMap> Attributes?

[Kal Ahmed]

On Fri, 2004-02-27 at 13:44, Murray Altheim wrote:
> Jan Algermissen wrote:
> > Hi,
> > 
> > I am working on ways to use XTM primarily as an exchange syntax for
> > topic maps and I think I need additional attributes on the
> > <mergeMap> element. This is *not* a proposal for changing XTM, but I
> > would be really happy if the authors of the various TM engines
> > could give me a hint if the XTM parsers would tolerate such
> > new attributes?  Or if they even support plugin code for customizing
> > the handling of <mergeMap>.
> > 
> > The background for my question is that I would like to (sometimes) use
> > <mergeMap> 'as the engine of application state'[1] for the client application.
> > In the same way as HTML <a href>'s do that in HTML.
> > 
> > A few initial thoughts on this are in [2], but a lot of this needs to be
> > straightened out of course.
> > 
> > Thanks in advance.
> > 
> > Jan
> > 
> > 
> > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_3
> > [2] http://www.topicmapping.com/blog/more_on_xtm_as_engine_of_application_state.html
> 
> Jan,
> 
> I think Kal will correct me if I'm wrong,
Just some small corrections :)

>  but my impression of
> the existing <mergemap> functionality and what you're trying to
> accomplish is that you don't need to suggest any changes to XTM
> syntax. The <mergeMap> element is a directive, unlike an #include
> or an SGML entity reference, it doesn't force the Topic Map engine
> to immediately load the referenced Topic Map document -- it's up
> to the application to do so at some appropriate time.
> 

I think that the topic map processing model *does* require all
<mergeMap> elements to be processed before you can claim to have an
conformant model of what is in the topic map. But it is certainly true
that TM4J gives you flexibility over whether/how you achieve this.

> So in TM4J, there's an addMergeMap(Locator,Scope) method that adds
> a directive to the list. You can use hasMergeMap(Locator) to
> determine if a specific directive (via its Locator) exists, and
> you can use getMergeMapLocators() to return a Java Collection
> containing *unresolved* mergeMap directives.
> 
> So in your case, you only (at the application level, not at the
> Topic Map engine level) resolve the mergeMaps when you want to,
> such as when the user demands information from a specific map.
> 

Thats all true. Of course, if you use TM4J's XTM parser "out of the
box", then you will lose the additional attributes - so you may want to
construct your parser chain by hand so that you can intercept the
attributes on the <mergeMap> element - but the flexibility is still
there in the API to do that.

One thing that comes to mind in reading Jan's proposal is that the topic
map in the HTTP response body ought to be able to provide the additional
information regarding the interaction pattern - so it could be a list of
mergeMap elements plus topics that reify each mergeMap resource and
provide the additional information.

Then, in TM4J at least, you could enumerate the list of mergeMap
locators, search for the topic that reifies the resource and extract and
display whatever pertinent information you received in the response
topicMap.

Cheers,

Kal

-- 
Kal Ahmed <kal@techquila.com>
techquila