Re: [Tm4j-developers] TopicMapProvider

[Gerd M. <ge...@sm...>]

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

It's not that special. Finally ozone is nothing more and nothing less than
a transactional swap for Java objects. There must be point where to put a
topicmap into the system and the system (ozone) has to know about the
topicmap. The logical conclusion is a addTopicMap() method.
 
> > 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.

registerProvider() should return the provider and the getProvider() method
may also be useful.
 
> 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.

Okay, I've forgot the xml:base attribute. I think you are right and we
leave it provider depend.
 
Another point: Now as the interface collection of topicmap grows
it would probably as good idea to create a separate package for
the in-memory implementation as you've already suggest some time
ago. 

With my latest check-ins of the ozone stuff I guess I'm ready for
the 0.5 distribution, except that we change something with the
provider interface.

Best Regards,
Gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com