[Tm4j-developers] [ tm4j-Bugs-1704268 ] Occurence may be member of zero to many different Topics

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #1704268, was opened at 2007-04-20 23:58
Message generated for change (Comment added) made by conal_tuohy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: In-Memory Impl
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Xuan Baldauf (mediumnet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Occurence may be member of zero to many different Topics

Initial Comment:
By analyzing the current code, I found out following:

(1) Occurences may be removed from their parent topic by calling setOccurences(new Occurence[0]) on the parent topic. Then, these occurences are orphaned.
(2) Occurences may be added to a different topic by calling setOccurences(new Occurence[foreignOccurence]) or by calling addOccurrence(foreignOccurence);
(3) Occurences may be added to a different topic by calling newTopic.setOccurences(new Occurence[foreignOccurence]) while still not being removed from the old parent.

Orphaned occurences are not supported by TMDM or by TMAPI. Moving occurences between different topics is also not supported by TMAPI. Support for orphaning occurences (for other reasons than to finally destroying them) and adding orphaned occurences should thus be removed. Thus, as a first step, the corresponding methods should be deprecated.

I'm not sure wether any TM4J application exists which moves occurences between topics.

I'm also not sure wether any TM4J applications exists which implicitly removes occurences from their parentTopic by calling parentTopic.setOccurences(smallerOccurenceArray) as opposed to just explicitly removing occurences by calling occurence.destroy().

If no such application exists, the methods Topic.addOccurrence() and Topic.setOccurrences() could be simply removed (the remaining functionality of Topic.setOccurences() would be just removing occurences, but this functionality is also available by calling occurence.destroy().)

----------------------------------------------------------------------

>Comment By: Conal Tuohy (conal_tuohy)
Date: 2008-03-10 19:06

Message:
Logged In: YES 
user_id=689468
Originator: NO

I agree with Lars that the interface shouldn't change because it is needed
by topic-merging applications.

Can we close this bug now? What do you say Xuan? Or should we discuss it
on the list?

----------------------------------------------------------------------

Comment By: Lars Heuer (lheuer)
Date: 2007-04-24 01:18

Message:
Logged In: YES 
user_id=399396
Originator: NO

My point is, that you need to be able to move roles, occurrences, names,
variants from one parent to another for merging purposes. So, you need to
keep track about them anyway (indexing etc.). The question is, if we want
to enable the user to move them or not. And, if you delegate all add<child>
/ remove<child> to the concrete implementations, you have to write a
merging procedure for each backend (or you introduce internal interfaces).

IMO the problem is not add<child>/remove<child> methods, but some bugs in
the TM4J code that do not set the correct parent and / or forget to
dereference the parent.

----------------------------------------------------------------------

Comment By: Xuan Baldauf (mediumnet)
Date: 2007-04-22 20:31

Message:
Logged In: YES 
user_id=506885
Originator: YES

One more comment regarding the conflict between the possiblity of orphaned
occurences with TMDM: TMDM not just requires the parent of an occurence to
be always set, but it tells also that the relationship between an occurence
and its parent is not simply a UML association, but a UML composition, as
you can judge from the black filled diamond at
http://www.isotopicmaps.org/sam/sam-model/#d0e1029 between Occurence and
Topic. That strongly means that an occurence may not exist without a
containing topic.

----------------------------------------------------------------------

Comment By: Xuan Baldauf (mediumnet)
Date: 2007-04-21 01:43

Message:
Logged In: YES 
user_id=506885
Originator: YES

Lars Heuer voiced concerns regarding the depreciation (and later removal)
of Topic.addOccurence() (using private e-mail, because the SF bug tracker
did not work temporarily). He also pointed out that this issue does not
only apply to Occurences.

It would be nice if you, Lars, could elaborate your point again here, if
you like.

I want to clarify that I do not intend to remove the implementation of
addOccurence() in TopicImpl, but I want to remove addOccurence() from the
interface Topic. Reasons are that else Occurences could be (at least
temporarily) without a parenting Topic, which would complicate indexing of
TopicMaps, be in contradiction to TMDM, be in contradiction to TMAPI.
Additionally, it would create more memory requirements, as then (new)
backends would be forced to support Occurences which belong to a particular
TopicMap, while not belonging to a particular topic, thus requiring the
Occurence to know its TopicMap explicitly (and not implictly by knowing its
Topic) which would require an extra pointer per Occurence (at least if
implemented straightforwardly).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1704268&group_id=27895