RE: [Tm4j-developers] TopicMapProvider

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

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

OK, if both of the existing implementations have an addTopicMap() method, I
guess it should probably be in the interface. I've added
addTopicMap(InputStream src, URL baseURL) to the TopicMapProvider interface.
The baseURL parameters should specify a URL to be assigned to the TopicMap
object only if the parser does not find a value in the topic map itself
(i.e. if the <topicMap> element does not have an xml:base attribute).

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

To support the addition of later import filters, I've added a getFactory()
method to the TopicMapProvider interface, this should return the
TopicMapFactory implementation which works with the TopicMapProvider's data
store. That should provide the necessary hook for a "syntax independant"
import process to be implemented later.

> > 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.
>
OK - I've done that now locally and I'll check it in soon.

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

Hopefully the updated interface will be suitable for you. I'll spend some
time today going through the documentation. Hopefully we will be able to
release by Friday.

Cheers,

Kal