Re: [Tm4j-developers] Proposal for solving the Ozone XTMBuilder "Problem"

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

Hi Harald,

Both of those suggestions make sense to me. I'm just in the process of
creating the 0.9.0a1 release. I think it would be worth doing these
changes for 0.9.0a2.

Cheers,

Kal

On Sun, 2003-11-23 at 09:10, Harald Kuhn wrote:
> Hi Kal,
> 
> I thought more about the "Probelm" we had with the Ozone backend having its own XTMBuilder. I you solved that for the time beeing but i think we need a more general solution. An XML Database for example would probably also have its own XTMBuilder. 
> 
> So i suggest delegating the decision for the "right" TopicMapBuilder to the TopicMapProvider so every backend can habe its own TopicMapBuilder implementations if the need arises.
> 
> I think adding a Method 
> 
> public TopicMapBuilder getBuilder(String notation);
> 
> would probably be enough. We can than add a general implementation to TopicMapSourceSupport and just override this in the Ozone Provider. The impact should be minimal as we wont change anything in the Builder.
> 
> A second thought arises to me while writing this. We could also add a new build 
> 
> public void build(InputStream src, Locator srcLoc, TopicMap tm)
> 
> method to the  TopicMapBuilders and depcrecate the old one. The Provider can be retrieved from the TopicMap object and so would not be needed anymore as a parameter in the build method. It also would prevent the accidental use of incompatibel TopicMapProvider and TopicMap implementations together.
> 
> 
> Cheers
> 
> Harald
> ______________________________________________________________________________
> Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
> Kostenlos downloaden: http://screensaver.web.de/?mc=021110
-- 
Kal Ahmed <ka...@te...>
techquila