#141 Occurence may be member of zero to many different Topics

open
nobody
5
2007-04-20
2007-04-20
Xuan Baldauf
No

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

Discussion

  • Xuan Baldauf
    Xuan Baldauf
    2007-04-20

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

     
  • Xuan Baldauf
    Xuan Baldauf
    2007-04-22

    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.

     
  • Lars Heuer
    Lars Heuer
    2007-04-23

    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.

     
  • Conal Tuohy
    Conal Tuohy
    2008-03-10

    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?

     
  • Having just today run upon this deprecation I can say that moving Occurrences between Topics or *deliberately* orphaning them during an editing operation are things that I've been doing for years. Arguments based on Topic Map theory (i.e., what "should/should not" or "may/may not" happen) are not appropriate here. TM4J is not a validating application, it is a Topic Map engine. If an engine is to be used in say, an editing application, it simply must be able to process constructs that are not at various times strictly valid. For example, during a cut and paste operation there is the time when the object is between origin and target -- orphaned. For reasons of backwards compatibility and sanity I would hope we could remove the deprecations.

     
  • Murray Altheim
    Murray Altheim
    2009-06-19

    Having just today run upon this deprecation I can say that moving Occurrences between Topics or *deliberately* orphaning them during an editing operation are things that I've been doing for years. This is an application-level responsibility, not something to be constrained by the engine.

    Arguments based on Topic Map theory (i.e., what "should/should not" or "may/may not" happen) are not appropriate here. TM4J is not a strictly validating application, it is a Topic Map engine. If an engine is to be used in say, an editing application, it simply must be able to process constructs that are not at various times strictly valid. For example, during a cut and paste operation there is the time when the object is between origin and target -- "orphaned". For reasons of backwards compatibility and sanity I would hope we could remove these and related deprecations.