[Tm4j-developers] Panckoucke - Next Version [long]

[Christoph F. <cf...@fo...>]

Hi

over the last weeks I had some conversations off-list concerning the
next version of panckoucke.
I collected the proposals and summarize them here. 

Every contribution - more proposals or comments on the existing ones -
is very appreciated.



Backward compatibility
-------------------------
Some of the proposals will have the effect, that the next version
wouldn't be backwards compatible with the current version 0.3
Is this is an important issue, taken the current spreading of panckoucke
into account? 



Proposals for the Abstractor-Interface
---------------------------------------------
1. Changes to the interface "Abstractor"
The signature of the two specified methods (generateModel(...) and
supportsAbstraction(...)) restricts the use of the Abstractors to
process *one* *TopicMapObject*. We would like to extend this to process
objects other than TopicMapObjects.
There are currently two proposals: 
a. Replacing the first parameter of type TopicMapObject with a parameter
of type Object. 
b. Changing the signature to generateModel(AbstractionTask).
AbstractionTask could be a new empty interface. Every Abstractor would
expect a distinct implementation of AbstractionTask. An implementation
will encapsulate all information necessary to perform the abstraction
process. A benefit of not-so-generic implementations of AbstractionTask
would be, that they clearly indicate the options suitable to this task.
This would be much more readable than the current practice where String
constants are passed via the hints-property of the AbstractionContext.


Proposals for the AbstractModel-API
---------------------------------------------
2. 
Using Lists instead of Sets
The collection of arcs, endnodes and represented objects should be
changed to use Lists rather than Sets.

Concerning the collections of arcs and endnodes, the matter is rather
clear, since the identity of a Node or an Arc in the AModel is not
defined. And apparently there was no need for it during the last two
years. Therefor using a Set does not add any meaning. Furthermore it
seems, that identity of nodes and arcs of a graph relies heavily on
their ordering position.
Concerning the collection of represented objects, it is not really
comprehensible why it should be illegal for an AMMember to represent a
collection of objects that contains duplicates.

While the significance of this proposal seems really clear, we have to
keep in mind, that it has the potential to break nearly every existing
panckoucke-client.


3. 
Weights
(This was already mentioned in some other threads on the list.)
The goal is to express some sort of 'scoring' for arcs and nodes.
It is not clear, if this feature should go to the core of the
abstraction model or would better be left to a specialisation of it
(WeightedModel extends AModel). Furthermore the details of its
implementation are unclear, but it is expectable that implementations of
weighted graph exists where we can learn about them.


4. 
Support for large topicmaps.
The next version of the abstract model should be implemented less naive
regarding the existance of larger topicmaps
Two issues:
a. Optimize the implementation in terms of memory usage (very important)
and speed (important, but less than memory)
b. Adding mechanics that restrict large lists (of nodes or arcs) to a
customisable number of items. The last (and eventually) the first item
of theese list would be an Arc or Node of special Gestalt. They would
hold a represented object that contains information about the current
and the next batch of items as well as information about the generation
of the model as a whole. 


5. 
Represented objects for models
The model itself should be able to represent objects.


6. 
Abstractor and Context in model.
The model may contain all information that were relevant to generate it.
This includes the Abstractor being used and all information that was
passed to generateModel(...)


7. 
Make the AMMember itself mutable.
Adding methods like addEndnode(AMNode) to AMNode/AMArc itself and
therefor get rid of the restriction that changing the graph is always
done through the model-interface. This would lead to much more readable
code.


8. 
Subgraphs.
Abstractors should be able to return several graphs. Therefor 
AModel could be enabled to hold several graphs, instead of only one.
Another approach would be to introduce a 'ModelGroup'. The ModelGroup
could be the return value of the generateModel(...) method??


9. 
Make the graph editable.
A use case: An application changes a given model, adds/removes/changes
Nodes and Arcs and pass the model back to some code (Harald calls this a
Concretizer) that is able to detect the changes and realizes them in the
source of the model, typically a topicmap. What additional properties
does a model need to support this idea? Something like a changeTracker,
that records additions, removals, updates? 


10. 
Make the model accessible through any of its member
A method getModel() in AMMember. Is this necessary? In consideration of
memory usage?


11. 
Add inheritance to the Gestalten.
This would enable us, as an example, to define a custom Gestalt
'Airport' as a specilisation of Gestalt 'Topic'. 
Code that processes the model and does know nothing about Airports could
therby fall back to rules for processing Topics.


12. 
Plain access to nodes and arcs
Add iterators to the model that let you iterate over all nodes and all
arcs contained in the model.
On the other hand this may also be done by an utility-method:
getNodeIterator(AModel)?? 



bye
c
-- 
Christoph Froehlich <cf...@fo...>