RE: [Tm4j-developers] TMNav

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

Hi  kal,

thanks for your analysis, with wich I agree completely

I was busy over the last weeks and this will last until end of july, 
but in august I will find some time to proceed developing tmnav. I 
would be glad to contribute to [5: lib] and since I am becoming an 
eclipse addict,  I would like to work on [3: Eclipse plugin]

When working on the prototype I stopped at a point, where two major task arose.
Since these tasks live at the very core of [5:lib], I will briefly 
mention them.

Firstly:
  [5:lib] should support visualisation in different levels-of-detail.
A very detailed level may show everything down to the single 
xml-elements, while a higher-level approach would summarize 
information and provide something which resembles more an overview. 
We talked about this before.

I will call this process the "summarization".

Summarization may leed to a model, where particular elements do not 
necessarily correspond directly to TopicMapElements. In fact some 
summarization-Elements will represent collections of topicMap 
Elements while other may symbolise constructs which are not even 
contained in the underlying map.
(Summarization will always be an interpretation, which may include 
the wish to add helper constructs)

  So secondly, we need a model
- which is the result of the summarisation-process and
- which has a very loose binding to the TopicMap-Model
- which is flexible enough to represent different degrees of visualisation and
- which is implementation independant.
I think, this will lead us to some abstract graph-model. So far so good.

But now it's getting diffcult.
There comes a time when we want the user to be able to interact with our app.
Perhaps he wants to delete the relation "all operas" from "composer verdi".

This means we must traverse the Summarization model back to the 
TopicMap-Model, in order to identify all TopicMap-Elements which are 
affected by this operation.  This is something like de-summarisation. 
It would be easy for isolated tasks, like deleting. But we need a 
more general approach, in order to enable developpers of using 
[5:lib] in a way, that we haven't had in mind, when implementing 
[5:lib].
This sounds difficult to me.


Puh. Sorry, if this kind of discussion is a bit off topic on this list.

What I wanted to say is I would like to contribute to tmnav.

But now back to work

regards
christoph

ps:
you aked me before, under which license eclipe is published. It is 
the "CPL", the "Common Public License".
Do yo know, what that license says?



>Hi all,
>
>I've been playing with Cristoph's excellent prototype application and thinking
>about the general approaches we could take to TMNav. In one conversation,
>someone (Cristoph ?) mentioned Eclipse[1] as an example of the kind of IDE
>framework within which TMNav could be built. I have taken a look at both
>Eclipse and NetBeans[2] and I can see the attraction in making TMNav a
>plug-in to one of these. Firstly there is alot of standard IDE stuff that
>these frameworks give you "for free" enabling us to concentrate on building
>cool, user-friendly visualisations and topic map editing capabilities.
>Secondly, there is a userbase for these tools already and those users will
>have less trouble getting started with a new plugin than having to learn a
>new application (and its IDE paradigm) from scratch. Thirdly, some of these
>frameworks might already have tools which we could hook in to (e.g. an XML
>editing plugin for viewing topic map source).
>
>However, there are some downsides to building a plugin. Firstly, which ever
>IDE you choose, you will neglect those who use the other one. Secondly, these
>IDEs are quite "heavy" - both in terms of size (big downloads) and complexity
>(take a fair bit of getting used to) - this makes them less than ideal for a
>novice user only interested in topic maps. Thirdly, integrating with a single
>IDE is limiting - a tight integration could prevent components of the TMNav
>plugin being repurposed.
>
>In fact, I think that TMNav should be all of the following:
>
>1) A stand-alone java application
>2) A servlet-based web app (possibly using java applets)
>3) A plugin for Eclipse
>4) A plugin for NetBeans
>5) A software library of reusable components for displaying and editing topic
>map data.
>
>It is (5) that I think enables (1) - (4). So what I am proposing is that we
>start work on a TMNav framework. I have some rough ideas about how this might
>be done which I am trying out with a simple example of doing (1) and (4)
>using the same visualisation components. However, I would definitely be
>interested to here the thoughts of others on this.
>
>Cheers,
>
>Kal
>
>[1] http://www.eclipse.org/
>[2] http://www.netbeans.org/
>
>--
>Kal Ahmed, techquila.com
>XML and Topic Map Consultancy
>
>e: ka...@te...
>p: +44 7968 529531
>w: www.techquila.com
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: Jabber - The world's fastest growing
>real-time communications platform! Don't just IM. Build it in!
>http://www.jabber.com/osdn/xim
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers