tm4j-developers — Forum for issues related to development of TM4J.

Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Kal Ahmed wrote:

> Hi,
> 
> At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
> 
>> this is a strange email. From whom are those interim quotes?
>> I can only recognize quotes to my mail and then on top
>> there are kals quotes. Who is this in between? :))
> 
> 
> Thats Gerd Mueller, developer of the Ozone back-end
> 
> 

Yes I know :) I just got your reply to Gerds mail earlier
than Gerds mail itself.


>>
>> - which interfaces would be changed?
>> - where is the copy implementation?
> 
> 
> OK. This is where I think we are. There are thre approaches to copying 
> currenlty on the table
> 
> 1) The back-end independent copier object method - as represented by 
> TopicMapCopier
> 2) Norbert's suggestion that copy() functions be implemented as part of 
> the interfaces of TopicMapObject and derived classes
> 3) Gerd's suggestion that copy() functions be implemented as part of the 
> interface of TopicMapFactory
> 

Just to stress this point enough. Every solution has to be 
backend-independent.
It is (without any doubt) a good idea to prefer (3). I like the idea because
inside a copy method the create..() methods are needed. And the Factory 
is the
place where they reside.
Should we put the copy implementation in the TopicMapFactory. This will 
change
TopicMapFactory to an abstract class. If we don't like this idea we should
have a further look at (1).


NoB

Next Generation Back-ends (was Re: [Tm4j-developers] some thoughts of TopicMapCopier)

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

Hi

I've taken the liberty of separating the copier discussion from the 
back-end discussion:

At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
> >> >
> >> > backend ideas:
> >> >
> >> > Today I asked about the interface and implementation stuff of the
> >> > backends. My thoughts were the same as kals that there should
> >> > be the possibility to have a single implementation of topicmap
> >> > administrative code.
> >> > At the moment there is an API which copes with TopicMaps and not
> >> > with backends. Through the lack of a definition of a backend the
> >> > TM API itself is made backend specific. For me thats the point
> >> > of doubling implementation in the memory and ozone code.
> >> > I think the backend has total different requirements than the
> >> > TopicMap. If we could define the requirements for a backend
> >> > and turn them into atomic backend operations and then into interfaces
> >> > we could easily build a pluggable backend. I don't know if there
> >> > are reasons while this would be a too heavy task. Gerd?
> >>
> >> That'S a nice idea. It would make it easier to develop other
> >> backends. But I'm not sure if it is really that easy to define
> >> such atomic operations. Do you've got any ideas on that ?
> >
>
>We have already something similar. A lot of Collection classes are
>used. In a simple understanding the interface of the Collections
>are one part of i/o operation (set,get,add,...). additionally there
>are implemented enhancements coping with the needs of a backend.
>This should be a good starting point to define such operations.
>
>
> >
> > I can think of two possible approaches:
> >
> > 1) A lot of the complexity is due to maintenance of various indices. All
> > the indexes are currently held as Hashtables or the like. Perhaps it
> > would be better to make these indices into first-class objects with
> > defined interfaces. Then a back-end would be responsible for
> > implementing persistent storage of the objects and the indices, and we
> > could slice off the index maintenance logic and make it back-end
> > independent. Essentially, we would implement the existing API in two
> > layers, an API layer providing the logic on top of an SPI layer
> > providing persistent storage and indexing services.
> >
>
>I'm off on this issue. I'm lacking detailled knowledge on the inner
>side of the API. Could you explain in a few words how the present
>structure acts?

The present structure really has both SPI and logic combined in a single 
layer. Basically, to implement the com.techquila.topicmap.* interfaces, you 
need to provide both the persistent storage and the logic for handling 
indexes, updates, deletions and so on. This makes development of a back-end 
a long and difficult process (sorry Florian! ;-). I am suggesting that we 
separate the logic that handles object updates, additions and deletions 
from the object and index persistence layer so that a backend needs only to 
implement the storage part.


> > 2) Implement a back-end service provider interface that requires the
> > implementation of a simpler data model such as PMTM4's node and arc
> > model, plus its supporting indexes then implement topic map specific
> > logic on top of that. If we are careful with such an implementation, it
> > might be possible to develop a single SPI which could support XTM and
> > ISO 13250 based APIs and could even support other node/arc based
> > technologies such as RDF.
> >
>
>That sounds intriguing. I don't know anything about PMTM4. Do you have
>links about this stuff?

Sorry, I meant to include one before I sent it. See 
http://www.topicmaps.net/pmtm4.htm

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
>this is a strange email. From whom are those interim quotes?
>I can only recognize quotes to my mail and then on top
>there are kals quotes. Who is this in between? :))

Thats Gerd Mueller, developer of the Ozone back-end


> >>
> >> Maybe I missed some point in this discussion, but why not having
> >> a copy() method at the factory interface ? Then I would write:
> >>
> >>   Topic t = factory.copy( topic, true );
> >>
> >> Then it would be clear in which topicmap the copy resists and it
> >> doesn't matter where the source comes from.
> >
> >
> > That's another good idea - after all, it may be possible for different
> > implementations to optimize the copy operation if they are all held in a
> > single base class. Of course, that makes a clone() operation more
> > difficult to implement, but only slightly so. If we implemented the
> > TopicMap back-pointer in TopicMapObject, then an object could do clone
> > by calling getTopicMap().getFactory().copy(...)
> >
>
>
>Ok, now I'm just not sure if everybody talks about the same issue.
>Let's fix this:
>
>- which interfaces would be changed?
>- where is the copy implementation?

OK. This is where I think we are. There are thre approaches to copying 
currenlty on the table

1) The back-end independent copier object method - as represented by 
TopicMapCopier
2) Norbert's suggestion that copy() functions be implemented as part of the 
interfaces of TopicMapObject and derived classes
3) Gerd's suggestion that copy() functions be implemented as part of the 
interface of TopicMapFactory

Then there are extra ideas flying round related to each of (2) and (3). As 
far as I can tell, (2) and (3) are equivalent in terms of functionality. 
(3) has the advantage that the factory being used for making the copy is clear.

Lets try and resolve the issue of which approach to take first and then 
analyze that approach in more detail. If we find problems, we can always 
return to the "choosing an approach" step again!

Lets move discussion of changes to the back-end into a separate thread.

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Hi,


this is a strange email. From whom are those interim quotes?
I can only recognize quotes to my mail and then on top
there are kals quotes. Who is this in between? :))

 >>
 >> Maybe I missed some point in this discussion, but why not having
 >> a copy() method at the factory interface ? Then I would write:
 >>
 >>   Topic t = factory.copy( topic, true );
 >>
 >> Then it would be clear in which topicmap the copy resists and it
 >> doesn't matter where the source comes from.
 >
 >
 > That's another good idea - after all, it may be possible for different
 > implementations to optimize the copy operation if they are all held in a
 > single base class. Of course, that makes a clone() operation more
 > difficult to implement, but only slightly so. If we implemented the
 > TopicMap back-pointer in TopicMapObject, then an object could do clone
 > by calling getTopicMap().getFactory().copy(...)
 >


Ok, now I'm just not sure if everybody talks about the same issue.
Let's fix this:

- which interfaces would be changed?
- where is the copy implementation?


 >> >
 >> > backend ideas:
 >> >
 >> > Today I asked about the interface and implementation stuff of the
 >> > backends. My thoughts were the same as kals that there should
 >> > be the possibility to have a single implementation of topicmap
 >> > administrative code.
 >> > At the moment there is an API which copes with TopicMaps and not
 >> > with backends. Through the lack of a definition of a backend the
 >> > TM API itself is made backend specific. For me thats the point
 >> > of doubling implementation in the memory and ozone code.
 >> > I think the backend has total different requirements than the
 >> > TopicMap. If we could define the requirements for a backend
 >> > and turn them into atomic backend operations and then into interfaces
 >> > we could easily build a pluggable backend. I don't know if there
 >> > are reasons while this would be a too heavy task. Gerd?
 >>
 >> That'S a nice idea. It would make it easier to develop other
 >> backends. But I'm not sure if it is really that easy to define
 >> such atomic operations. Do you've got any ideas on that ?
 >

We have already something similar. A lot of Collection classes are
used. In a simple understanding the interface of the Collections
are one part of i/o operation (set,get,add,...). additionally there
are implemented enhancements coping with the needs of a backend.
This should be a good starting point to define such operations.


 >
 > I can think of two possible approaches:
 >
 > 1) A lot of the complexity is due to maintenance of various indices. All
 > the indexes are currently held as Hashtables or the like. Perhaps it
 > would be better to make these indices into first-class objects with
 > defined interfaces. Then a back-end would be responsible for
 > implementing persistent storage of the objects and the indices, and we
 > could slice off the index maintenance logic and make it back-end
 > independent. Essentially, we would implement the existing API in two
 > layers, an API layer providing the logic on top of an SPI layer
 > providing persistent storage and indexing services.
 >

I'm off on this issue. I'm lacking detailled knowledge on the inner
side of the API. Could you explain in a few words how the present
structure acts?


 > 2) Implement a back-end service provider interface that requires the
 > implementation of a simpler data model such as PMTM4's node and arc
 > model, plus its supporting indexes then implement topic map specific
 > logic on top of that. If we are careful with such an implementation, it
 > might be possible to develop a single SPI which could support XTM and
 > ISO 13250 based APIs and could even support other node/arc based
 > technologies such as RDF.
 >

That sounds intriguing. I don't know anything about PMTM4. Do you have
links about this stuff?


NoB

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

> thats a lot of stuff and new thoughts which are mixed together.
> 
> 
> - having static copy methods
> - where the methods will reside
> - putting complex code in base classes
> - thinking about backend stuff
> - putting a copy factory in topicmap
> 
> Having static methods is sure a quite good deal. I don't really have
> 
> a preference where they should live.
> The static methods could reside in the object implementations while
> they are object specific. On the other side every static methods
> gets his working stuff as a parameter. This opens the options to
> put them into an extra class.
> 
> If I understand you right then the copyFactory has something to do
> with the deep copy. In this situation we need a factory for creation
> of subcomponents. If I assume the static methods we have
> 
> 	copy(Topic srcTopic, Topic destTopic, boolean deep)
> 
> On the other site we have in TopicMap
> 
> 	setCopyFactory(TopicMapFactory copyFactory)
> 
> I think it is dangerous to assume that the factory of destTopic and
> copyFactory are always the same. In my opinion we should have an assurance
> that the factory of e.g. a Topic and his components (BaseName, Occurrence)
> is the same. If this isn't clear here a example:
> 
> 	Topic src;
> 	TopicMapFactory f1;
> 	TopicMapFactory f2;
> 	TopicMap tm;
> 
> 	tm.setCopyFactory(f1);
> 	Topic dest = f2.createTopic();
> 
> 	Topic.copy(src, dest, true);
> 
> What will happen? A Topic src in a TopicMap from f1 and BaseNames
> in TopicMap from f2 ??
> 
> As long as I can see TopicMap is the only class which knows his factory.
> That looks good. Is there any reason why a TopicMapObject shouldn't
> know his Map? Every Object is only working in one TopicMap (through
> references). If every TopicMapObjects knows his Map/Ownermap we could
> check such things like illegal movement from one topicmap to another.
> And we can always get the right factory through 
> this.getOwnerMap().getFactory();
> This way we wouldn't need copyFactory, we could use loads of different
> factories and the case of copying from a memory map to ozone is coped.

Maybe I missed some point in this discussion, but why not having
a copy() method at the factory interface ? Then I would write:

  Topic t = factory.copy( topic, true );
     
Then it would be clear in which topicmap the copy resists and it
doesn't matter where the source comes from. 

> 
> backend ideas:
> 
> Today I asked about the interface and implementation stuff of the
> backends. My thoughts were the same as kals that there should
> be the possibility to have a single implementation of topicmap
> administrative code.
> At the moment there is an API which copes with TopicMaps and not
> with backends. Through the lack of a definition of a backend the
> TM API itself is made backend specific. For me thats the point
> of doubling implementation in the memory and ozone code.
> I think the backend has total different requirements than the
> TopicMap. If we could define the requirements for a backend
> and turn them into atomic backend operations and then into interfaces
> we could easily build a pluggable backend. I don't know if there
> are reasons while this would be a too heavy task. Gerd?

That'S a nice idea. It would make it easier to develop other
backends. But I'm not sure if it is really that easy to define
such atomic operations. Do you've got any ideas on that ?

Bye,
gerd

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

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

At 09:20 28/09/2001 +0200, you wrote:
>Hi,
>
> > thats a lot of stuff and new thoughts which are mixed together.
> >
> >
> > - having static copy methods
> > - where the methods will reside
> > - putting complex code in base classes
> > - thinking about backend stuff
> > - putting a copy factory in topicmap
> >
> > Having static methods is sure a quite good deal. I don't really have
> >
> > a preference where they should live.
> > The static methods could reside in the object implementations while
> > they are object specific. On the other side every static methods
> > gets his working stuff as a parameter. This opens the options to
> > put them into an extra class.
> >
> > If I understand you right then the copyFactory has something to do
> > with the deep copy. In this situation we need a factory for creation
> > of subcomponents. If I assume the static methods we have
> >
> >       copy(Topic srcTopic, Topic destTopic, boolean deep)
> >
> > On the other site we have in TopicMap
> >
> >       setCopyFactory(TopicMapFactory copyFactory)
> >
> > I think it is dangerous to assume that the factory of destTopic and
> > copyFactory are always the same. In my opinion we should have an assurance
> > that the factory of e.g. a Topic and his components (BaseName, Occurrence)
> > is the same. If this isn't clear here a example:
> >
> >       Topic src;
> >       TopicMapFactory f1;
> >       TopicMapFactory f2;
> >       TopicMap tm;
> >
> >       tm.setCopyFactory(f1);
> >       Topic dest = f2.createTopic();
> >
> >       Topic.copy(src, dest, true);
> >
> > What will happen? A Topic src in a TopicMap from f1 and BaseNames
> > in TopicMap from f2 ??
> >
> > As long as I can see TopicMap is the only class which knows his factory.
> > That looks good. Is there any reason why a TopicMapObject shouldn't
> > know his Map? Every Object is only working in one TopicMap (through
> > references). If every TopicMapObjects knows his Map/Ownermap we could
> > check such things like illegal movement from one topicmap to another.
> > And we can always get the right factory through
> > this.getOwnerMap().getFactory();
> > This way we wouldn't need copyFactory, we could use loads of different
> > factories and the case of copying from a memory map to ozone is coped.
>
>Maybe I missed some point in this discussion, but why not having
>a copy() method at the factory interface ? Then I would write:
>
>   Topic t = factory.copy( topic, true );
>
>Then it would be clear in which topicmap the copy resists and it
>doesn't matter where the source comes from.

That's another good idea - after all, it may be possible for different 
implementations to optimize the copy operation if they are all held in a 
single base class. Of course, that makes a clone() operation more difficult 
to implement, but only slightly so. If we implemented the TopicMap 
back-pointer in TopicMapObject, then an object could do clone by calling 
getTopicMap().getFactory().copy(...)

> >
> > backend ideas:
> >
> > Today I asked about the interface and implementation stuff of the
> > backends. My thoughts were the same as kals that there should
> > be the possibility to have a single implementation of topicmap
> > administrative code.
> > At the moment there is an API which copes with TopicMaps and not
> > with backends. Through the lack of a definition of a backend the
> > TM API itself is made backend specific. For me thats the point
> > of doubling implementation in the memory and ozone code.
> > I think the backend has total different requirements than the
> > TopicMap. If we could define the requirements for a backend
> > and turn them into atomic backend operations and then into interfaces
> > we could easily build a pluggable backend. I don't know if there
> > are reasons while this would be a too heavy task. Gerd?
>
>That'S a nice idea. It would make it easier to develop other
>backends. But I'm not sure if it is really that easy to define
>such atomic operations. Do you've got any ideas on that ?

I can think of two possible approaches:

1) A lot of the complexity is due to maintenance of various indices. All 
the indexes are currently held as Hashtables or the like. Perhaps it would 
be better to make these indices into first-class objects with defined 
interfaces. Then a back-end would be responsible for implementing 
persistent storage of the objects and the indices, and we could slice off 
the index maintenance logic and make it back-end independent. Essentially, 
we would implement the existing API in two layers, an API layer providing 
the logic on top of an SPI layer providing persistent storage and indexing 
services.

2) Implement a back-end service provider interface that requires the 
implementation of a simpler data model such as PMTM4's node and arc model, 
plus its supporting indexes then implement topic map specific logic on top 
of that. If we are careful with such an implementation, it might be 
possible to develop a single SPI which could support XTM and ISO 13250 
based APIs and could even support other node/arc based technologies such as 
RDF.

Thoughts ?

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Oops,

thats a lot of stuff and new thoughts which are mixed together.


- having static copy methods
- where the methods will reside
- putting complex code in base classes
- thinking about backend stuff
- putting a copy factory in topicmap

Having static methods is sure a quite good deal. I don't really have

a preference where they should live.
The static methods could reside in the object implementations while
they are object specific. On the other side every static methods
gets his working stuff as a parameter. This opens the options to
put them into an extra class.

If I understand you right then the copyFactory has something to do
with the deep copy. In this situation we need a factory for creation
of subcomponents. If I assume the static methods we have

	copy(Topic srcTopic, Topic destTopic, boolean deep)

On the other site we have in TopicMap

	setCopyFactory(TopicMapFactory copyFactory)

I think it is dangerous to assume that the factory of destTopic and
copyFactory are always the same. In my opinion we should have an assurance
that the factory of e.g. a Topic and his components (BaseName, Occurrence)
is the same. If this isn't clear here a example:

	Topic src;
	TopicMapFactory f1;
	TopicMapFactory f2;
	TopicMap tm;

	tm.setCopyFactory(f1);
	Topic dest = f2.createTopic();

	Topic.copy(src, dest, true);

What will happen? A Topic src in a TopicMap from f1 and BaseNames
in TopicMap from f2 ??

As long as I can see TopicMap is the only class which knows his factory.
That looks good. Is there any reason why a TopicMapObject shouldn't
know his Map? Every Object is only working in one TopicMap (through
references). If every TopicMapObjects knows his Map/Ownermap we could
check such things like illegal movement from one topicmap to another.
And we can always get the right factory through 
this.getOwnerMap().getFactory();
This way we wouldn't need copyFactory, we could use loads of different
factories and the case of copying from a memory map to ozone is coped.


backend ideas:

Today I asked about the interface and implementation stuff of the
backends. My thoughts were the same as kals that there should
be the possibility to have a single implementation of topicmap
administrative code.
At the moment there is an API which copes with TopicMaps and not
with backends. Through the lack of a definition of a backend the
TM API itself is made backend specific. For me thats the point
of doubling implementation in the memory and ozone code.
I think the backend has total different requirements than the
TopicMap. If we could define the requirements for a backend
and turn them into atomic backend operations and then into interfaces
we could easily build a pluggable backend. I don't know if there
are reasons while this would be a too heavy task. Gerd?

If this sounds reasonable kals proposal of base classes would
lead to the only implementation of logic/administrative topicmap
specific code. The other part will then be a plugable backend
provider which provides any i/o operation on the backend.


just a few words to confuse the world around me :)


sincerely,

NoB

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

OK, I'll try again without hitting Emacs control keys in a non-emacs 
environment ;-)

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>[kal]
>
>I am very lucky to see that the copying stuff has just started.
>It's one of those functionalities I need most these days.
>I had a peak view at the TopicMapCopier class. And from there
>some questions arose.
>
>As long as I understand the copying problem it depends on
>the origins (or factories/owners) of the objects and the type
>of copying (shallow/deep).
>
>involved objects/params are:
>
>- sourceObject
>- destObject (created from sourceObjects factory or a different one)
>- shallow/deep copy switch
>
>which in my thoughts would lead to a basic method
>
>copy(srcObj, destObj, deep)
>
>in case of class Topic:
>
>copy(Topic srcTopic, Topic destTopic, boolean deep)
>
>This method could be a static method of class topic.
>Or like an example in Collections class collected
>in a utility class (see Collections.copy(List,List)).
>
>Having such static methods it is easy to create other
>needed functionalities e.g. clone().
>
>assuming factory is the factory of the topicmap containing
>srcTopic a clone() method would be like that:
>
>public Object clone()
>{
>    Topic dest = factory.createTopic();
>    return copy(this, dest, false);
>}
>
>Additionally we don't need all time to create a util class
>to duplicate an object.

These are all good points. I think you have convinced me that static copy 
methods would be a Good Thing. My reason for making the TopicMapCopier a 
separate object is that it uses only the standard interfaces and so is not 
implementation-specific. If we make static copy methods, then perhaps we 
should create abstract base classes in the org.tm4j.topicmap package which 
implement those methods.

As I typed that I began to think that there are some other pieces of pretty 
complex logic which might also be better off moved into an abstract base 
class to allow reuse in other backend implementations.


>If we have the copying functionality in the object itself
>the utility class could cope with comfortability. In the
>present TopicMapCopier the factory is always the same.
>So we could store one specific factory in the TopicMapCopier
>and create copies of Objects automagically.
>
>This would lead from
>
>    public Topic copy(Topic t)
>    { ... }
>
>    to
>
>    public Topic copy(Topic t, boolean  deep)
>    {
>       Topic ret = m_dest.getFactory().createTopic....;
>       return Topic.copy(t, ret, deep);
>    }
>
>or something similar.

Actually, perhaps it would be better to get rid of TopicMapCopier 
completely and to make the factory to be used for creating copied objects 
into a property of the TopicMap (or TopicMapUtils) interface, with a 
default value set to the factory used to create the topic map in the first 
place. That way, the static copy() functions can use a runtime-configured 
factory (enabling me to copy from an Ozone database into an in-memory 
implementation for local modification, for example).

>I would also prefer not to use two different method names
>like copy() and deepCopy(). If there are requirements to
>have automated decision of shallow/deep this comes into place.
>The kind of copy is done via a switch. A switch mostly forms
>itself as an ifElse statements.
>While the method names are chosen at compile time the programmer
>using the API has to write an ifElse statement to decide which
>copy should be made. With a switch in the method this functionality
>moves into the API and appears more comfortable.
>Additional there is the possibility to define a default behaviour
>having a method without the switch parameter.
>
>what do you think?

I was in two minds about that when I wrote the TopicMapCopier class...I'm 
not now sure why I chose to use two different names. I think it was because 
I felt that copy() and deepCopy() were getting overloaded enough...but if 
we have them in the interfaces, then that problem goes away and a boolean 
flag is appropriate.

So in summary:

1) implement copy() in each object interface - note, this includes 
interfaces such as TopicMapObject
2) Put the implementations in abstract base classes and change the memory 
and ozone implementations to extend the base classes.
2) Add a getCopyFactory() method to TopicMap which defaults to the factory 
used for the TopicMap
3) Add a setCopyFactory() method to TopicMap which enables the user to 
provide a new Factory to use for copying
4) copy() supports deep and shallow copies according to the value of a 
boolean flag passed in to the copy() method.


>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>[kal]
>
>I am very lucky to see that the copying stuff has just started.
>It's one of those functionalities I need most these days.
>I had a peak view at the TopicMapCopier class. And from there
>some questions arose.
>
>As long as I understand the copying problem it depends on
>the origins (or factories/owners) of the objects and the type
>of copying (shallow/deep).
>
>involved objects/params are:
>
>- sourceObject
>- destObject (created from sourceObjects factory or a different one)
>- shallow/deep copy switch
>
>which in my thoughts would lead to a basic method
>
>copy(srcObj, destObj, deep)
>
>in case of class Topic:
>
>copy(Topic srcTopic, Topic destTopic, boolean deep)
>
>This method could be a static method of class topic.
>Or like an example in Collections class collected
>in a utility class (see Collections.copy(List,List)).
>
>Having such static methods it is easy to create other
>needed functionalities e.g. clone().

Thats a good point.

>assuming factory is the factory of the topicmap containing
>srcTopic a clone() method would be like that:
>
>public Object clone()
>{
>    Topic dest = factory.createTopic();
>    return copy(this, dest, false);
>}

That could be done too.

>Additionally we don't need all time to create a util class
>to duplicate an object.

Definitely an advantage.

>If we have the copying functionality in the object itself
>the utility class could cope with comfortability. In the
>present TopicMapCopier the factory is always the same.
>So we could store one specific factory in the TopicMapCopier
>and create copies of Objects automagically.
>
>This would lead from
>
>    public Topic copy(Topic t)
>    { ... }
>
>    to
>
>    public Topic copy(Topic t, boolean  deep)
>    {
>       Topic ret = m_dest.getFactory().createTopic....;
>       return Topic.copy(t, ret, deep);
>    }
>
>or something similar.

Perhaps we could eliminate TopicMapCopier completely and make the factory 
to be used for creating copies into a p

>I would also prefer not to use two different method names
>like copy() and deepCopy(). If there are requirements to
>have automated decision of shallow/deep this comes into place.
>The kind of copy is done via a switch. A switch mostly forms
>itself as an ifElse statements.
>While the method names are chosen at compile time the programmer
>using the API has to write an ifElse statement to decide which
>copy should be made. With a switch in the method this functionality
>moves into the API and appears more comfortable.
>Additional there is the possibility to define a default behaviour
>having a method without the switch parameter.
>
>what do you think?
>
>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

Re: [Tm4j-developers] backend question

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

At 15:37 27/09/2001 +0200, Gerd Mueller wrote:

> > Hi,
> >
> > I have some backend questions:
> >
> > - Why does ozone have a different set of topicmap interfaces?
>
>These interfaces are necessary to markup the update methods.
>Also the extend OzoneProxy which is important for ozone. But
>the methods are exactly the same as the usual tm4j interfaces.
>
> > - What's the difference between the memory...Impl and
> >    the ozone...Impl classes?
>
>I hope there is no difference in terms of functionality, but I
>had to make some ozone specific changes.

Would there be any way to make use of inheritance and localise only the 
ozone specific changes within the ozone Impl classes ? Even if it means 
having to make calls to super.xxx() it would at least mean that bug fixes 
need only be done once...I try to be as lazy as possible ;-)

Cheers,

Kal

Re: [Tm4j-developers] backend question

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

> Hi,
> 
> I have some backend questions:
> 
> - Why does ozone have a different set of topicmap interfaces?

These interfaces are necessary to markup the update methods.
Also the extend OzoneProxy which is important for ozone. But
the methods are exactly the same as the usual tm4j interfaces.

> - What's the difference between the memory...Impl and
>    the ozone...Impl classes?

I hope there is no difference in terms of functionality, but I
had to make some ozone specific changes.

Best Regards,
Gerd

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

[Tm4j-developers] backend question

[Norbert H. <rue...@se...>]

Hi,

I have some backend questions:

- Why does ozone have a different set of topicmap interfaces?
- What's the difference between the memory...Impl and
   the ozone...Impl classes?

thanks in advance,

NoB

[Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Hi,

[kal]

I am very lucky to see that the copying stuff has just started.
It's one of those functionalities I need most these days.
I had a peak view at the TopicMapCopier class. And from there
some questions arose.

As long as I understand the copying problem it depends on
the origins (or factories/owners) of the objects and the type
of copying (shallow/deep).

involved objects/params are:

- sourceObject
- destObject (created from sourceObjects factory or a different one)
- shallow/deep copy switch

which in my thoughts would lead to a basic method

copy(srcObj, destObj, deep)

in case of class Topic:

copy(Topic srcTopic, Topic destTopic, boolean deep)

This method could be a static method of class topic.
Or like an example in Collections class collected
in a utility class (see Collections.copy(List,List)).

Having such static methods it is easy to create other
needed functionalities e.g. clone().

assuming factory is the factory of the topicmap containing
srcTopic a clone() method would be like that:

public Object clone()
{
    Topic dest = factory.createTopic();
    return copy(this, dest, false);
}

Additionally we don't need all time to create a util class
to duplicate an object.

If we have the copying functionality in the object itself
the utility class could cope with comfortability. In the
present TopicMapCopier the factory is always the same.
So we could store one specific factory in the TopicMapCopier
and create copies of Objects automagically.

This would lead from

    public Topic copy(Topic t)
    { ... }

    to

    public Topic copy(Topic t, boolean  deep)
    {
       Topic ret = m_dest.getFactory().createTopic....;
       return Topic.copy(t, ret, deep);
    }

or something similar.

I would also prefer not to use two different method names
like copy() and deepCopy(). If there are requirements to
have automated decision of shallow/deep this comes into place.
The kind of copy is done via a switch. A switch mostly forms
itself as an ifElse statements.
While the method names are chosen at compile time the programmer
using the API has to write an ifElse statement to decide which
copy should be made. With a switch in the method this functionality
moves into the API and appears more comfortable.
Additional there is the possibility to define a default behaviour
having a method without the switch parameter.

what do you think?

NoB

[Tm4j-developers] Package name change.

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

Hi all,

As you have probably noticed, Norbert has started checking code in under 
the new TM4J package hierarchy, org.tm4j rather than com.techquila. I am 
planning to move the code base across to org.tm4j over this weekend. If any 
of you have code changes that you would like to get into CVS, please check 
them in before...lets say 17:00 GMT on Friday 28th.

Cheers,

Kal

Re: [Tm4j-developers] missing class file

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

At 10:45 25/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>i checked out the HEAD branch from cvs. I cannot
>compile the source because source file
>DuplicateObjectIDException is missing in cvs.

Oops! My bad...I've commited the new file 
(src/com/techquila/topicmap/DuplicateObjectIDException.java) now.

Cheers,

Kal

[Tm4j-developers] missing class file

[Norbert H. <rue...@se...>]

Hi,

i checked out the HEAD branch from cvs. I cannot
compile the source because source file
DuplicateObjectIDException is missing in cvs.


best regards,

NoB

[Tm4j-developers] TMEdit features

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

Hi all,

Sorry about the long hiatus.

I started trying to write down a feature list for TMEdit to share as a
starting point for discussion. Then I realised that this should  be a topic
map! In fact as an experiment I think it would be interesting to attempt to
track the whole design process for TMEdit in a topic map. What do others
think ?

Attached is a zip file containing an XTM topic map and a set of Protege
project files. You should be able to load the XTM file into your favourite
topic map browser application (!) or alternatively get hold of Protege 1.6
beta from http://smi.stanford.edu/projects/protege/index.html and open the
file tmedit.pprj in it. The conversion from Protege file to topic map was
done using a plugin I developed for Protege called TMTab
(http://www.techquila.com/tmtab/index.html). For those of you who haven't
played with Protege before, it is really worthwhile doing so - it has a lot
of neat features, some of which should probably also make their way into
TMEdit!

Cheers,

Kal

BTW - feel free to tell me if you think that topic mapping the design
process is not a good idea...

-----------------------------------
Kal Ahmed
XML and Topic Maps Consultant
e: ka...@te...
p: +44 (0)7968 529 531
w: www.techquila.com
-----------------------------------

[Tm4j-developers] Typo in CVS log message

[Florian G. H. <f.g...@gm...>]

Excuse the typo in the log message you may have received via tm4j-commits.
The package name is, of course, "com.techquila.topicmap.dom".

:-)
my apologies,
-- Florian

----------------------------------------------
Florian G. Haas
FHS Informationsberufe, Eisenstadt, Austria
http://info.fh-eisenstadt.ac.at/~haasf/

[Tm4j-developers] Test message

[Jack P. <jac...@th...>]

This is a test to see if I can actually respond to this list.  In the past, 
sourceforge rejected my responses.  I just learned this morning that I 
needed a "postmaster" account which I just set up.

Cheers
Jack

Re: [Tm4j-developers] Testcode & CVS

[Norbert H. <rue...@se...>]

Hi,

> E.g. some input parameters as the name of a TopicMap file. This way
> don't need to hard code such things as filenames and can use
> the same test with different input data.

One issue is the invocation of a specific backend. Could you please
explain to me what is needed to do a basic setup of the ozone db?
For testing I assume it is likely to setup a clean ozone-db in
the TestCases itself.

NoB

Re: [Tm4j-developers] Testcode & CVS

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

Hi,

> There is one issue left on the test code packages. I'm just used
> to have parallel packages. There isn't a good reason not to
> have nested packages. I think the most important part is to
> have a guideline which everybody can agree.
> 
> Ok, we'll use subpackages for testcode. package a.b.c will have
> a test code package a.b.c.test.
> 
> Gerd: it would be nice if you could explain more detailed what
> you want to configure via property files.

E.g. some input parameters as the name of a TopicMap file. This way
don't need to hard code such things as filenames and can use
the same test with different input data.
 
Best Regards,
Gerd

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

[Tm4j-developers] (no subject)

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

[Tm4j-developers] (no subject)

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

[Tm4j-developers] (no subject)

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

[Tm4j-developers] (no subject)

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