RE: [Tm4j-developers] TopicMapProvider

[Kal A. <ka...@te...>]

Hi Gerd,

>
> > What you describe sounds like a generic "import" method for the
> > TopicMapProvider interface - essentially a way for an
> application programmer
> > to easily code the task of parsing an XTM file and storing it
> in whatever
> > underlying topic map store is being used by the system. Is that
> correct ?
>
> Yeap, that's what I was thinking of. The problem was that I've implemented
> the TopicMapProvider stuff, but I didn't know what to provide since that
> database was empty. Thus I've needed a addTopicMap method somehow. And as
> I saw, you've already added such method to the in-memory implementation.
>
Yep, I did, though I consider that to be a bit of a special case, because
the in-memory implementation has not persistant store. In other words, it
*has* to add new topic maps somehow.

> > If so, I'm not sure that TopicMapProvider is necessarily the
> right place to
> > add this functionality - generic import and export interfaces would
> > definitely be useful and the TopicMapManager interface makes it
> relatively
> > easy to implement, but I think I would prefer to have a
> separate interface
> > for store-independant and syntax-independant import/export - I
> am thinking
> > that in the future it would be good to reintroduce support for
> reading and
> > possibly writing ISO 13250 syntax and for reading and possibly writing
> > Ontopia's LTM syntax. For that reason I would prefer to
> encapsulate import
> > and export in some interface(s) separate from TopicMapProvider.
> What do you
> > think ?
>
> Sounds really good. But IMHO the Import/Export interfaces must be
> connected
> somehow with a provider, because finally the provider knows how to store
> the topicmap. E.g. a provider could have a method like
> ImportFilter getImportFilter( String format ) or something like that.
>

That is an interesting possibility. So an ImportFilter would essentially
wrap an parser object, and a builder object with the appropriate factory for
the store which the TopicMapProvider wraps. That sounds quite neat. Though
then we may need to also add some way of getting hold of the
TopicMapProvider from the TopicMapManager object - perhaps returning it from
the registerProvider() method, or maybe by adding a getProvider( TopicMap )
method to the TopicMapManager interface.

> The next thing I was thinking about is the base URL of a topic map.
> Should a provider have a base URL and all topicmaps which it provides
> are 'folders' of this URL ? E.g. the ozone provider has
> http://topicmap.techquila.com/ozone, thus a topicmap provided by this
> has http://topicmap.techquila.com/ozone/the_name_of_the_tm
>

I think that this should be provider dependent - what you describe certainly
makes sense for a persistant storage-backed implementation, but probably
doesn't make sense for the in-memory implementation where the system is
parsing files from a file system or from the Web. There is another issue
here as well, currently the XTMParser object will honour the xml:base
attribute if it is found on the <topicMap> object - the URL specified in
that attribute will then become the value of the base property of the
TopicMap object. This is important because enables me to import a topic map
with a "well-known" URL into a topic map store and for references between
topic maps to be resolved correctly. It is the value of the base property
which the in-memory provider makes use of.

Of course, it could also be possible for an implementation to recognise
multiple URLs for the same topic map - so the Ozone provider may support
addressing as you suggest as well as addressing by the base property of the
TopicMap object, but should probably only return its 'generated' base URL if
the TopicMap does not have a value for the 'base' property.

> And what about the name of topicmap ? Is it user-defined or
> auto generated ?
>

The in-memory implementation uses the value of the xml:base attribute or
else a default URL as the base property of the imported topic map. I'm not
entirely happy with a single default URL so I think future behaviour of the
in-memory implementation will be to default to some generated,
session-unique value.

For the Ozone implementation I would suggest that some similar algorithm
should be employed.

> I've noticed that you checked in a developer doc made with
> docbook. Which tool do you use for that ?
>

I used XMetal for creating that document. XMetal is probably my favourite
XML editor - and I've tried a few - though I have a love-hate relationship
with all of them. :-)

Cheers,

Kal