RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)

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

At 18:56 13/02/2002 +0100, Florian G. Haas wrote:
>Kal,
>
>I very much like your ideas. Sound like a lot of work, but great ideas
>nevertheless! :-)
>
>Well, as for another feature, I realize I might be jumping the gun a little
>bit, but while we're talking about dynamic, possibly XSLT-centered web
>applications, shouldn't we give an SVG front-end a thought? Anyone up for
>that? (I realize this definitely sounds like a post-0.7.0 or even post-1.0
>feature)

That sounds way cool - actually, I saw a presentation on this subject at 
XML 2001 last year - the presenter had combined SVG graphics for 
presentation with some statistically-based filtering which "clusters" the 
topic map into regions and subregions. Sounds like the kind of interesting 
thing which should be built on TM4J ;-)

>BUT, aside from all that, let me humbly pitch in my idea that perhaps we
>shouldn't get all too excited now about new cool stuff we are planning to
>incorporate into TM4J. Maybe we should take a little time for QA issues, and
>documentation. The dev guide is great (hats off, Kal), but as Tim Smith has
>thankfully pointed out, the rest of the documentation may still be lacking a
>number of touch-ups. I realize I may be spoiling everybody's fun to a
>certain extent, but I believe that if we want to get people working with
>this thing, we had better get it into a condition where they can use it as
>an out-of-the-box tool. So I agree with you, Kal, about the issues you
>consider "REQUIRED" (because those are the ones that will get TM4J into
>exactly that condition), but I really believe we should put other insane
>features -- like the one I mention above :-) -- off for the moment.

Ah ! The voice of reason ! ;-)

I deliberately threw a lot of stuff into the feature list so that we could 
start by choosing the stuff we really really want in 0.7.0 and then try and 
work out a longer term road-map for implementing the other stuff. But I 
must admit that I did miss out documentation improvements and I shouldn't 
have done so. We *do* need much better documentation. Preferably topic 
mapped! The developer's guide is a start, but the work that Florian has 
done on the project topic map and the start of a FAQ topic map should 
definitely be persued.

So lets add

  - Developer's documentation
       Installation and Building Guide
       Developer's Guide
       Developer's FAQ

to the list.


>A couple of QA issues that would jump to my mind:
>
>* Have we yet even decided on whether we want to follow Appendix F of the
>XTM spec (http://www.topicmaps.org/xtm/1.0/#processing) or PMTM
>(http://www.topicmaps.net/pmtm4.htm) in terms of TM processing? Or do we
>want to make this pluggable functionality, leaving it up to the user to
>decide on the processing model? The implementations available indicate that
>for now, we're sticking to Annex F, but have we ever put that down for other
>people to realize?

It is true that I developed a data model with the intention to support 
Annex F, rather than PMTM4 (which didn't really exist when I started on 
this). PMTM4 could probably be supported in a layer over an Annex F 
compliant TM processor (actually, it would be an interesting exercise to 
try this and see where any mismatches occur). We should document that we 
are working towards full XTM 1.0 Conformance (including Annex F).

>* Assuming for a moment that we do go for Annex F, how are we doing on
>association merging? Role player duplicate suppression? Equality and
>equivalence principles? Hierarchical variant-inside-variant processing?
>Equivalence of <instanceOf> and the class-instance association in XTM
>parsing?

Some of these are already handled - e.g. Topic.addType() creates a 
class-instance association as well as updating the types property of the 
topic. The XTM Compressor (possible a bad name) - 
org.tm4j.topicmap.utils.Compressor implements much of Annex F, but it does 
so as a post-processing operation which can be quite time-consuming for 
bigger topic maps.

One of the issues of full XTM 1.0 conformance is that XTM 1.0 assumes that 
when two topics are merged only one topic remains - this is not true in 
TM4J - I wanted to allow programmers to merge and "unmerge" topics and to 
be able to programmatically find out what topics were merged together - I 
believe that these will be useful features in manual topic map generation 
and merging ("Wait, I didn't want those topics to merge! Let me just change 
the scope name of the second topic..." - that would be impossible if the 
processor had already compressed the two topics into a single object).

However, I don't think that this is an insurmountable problem - there are a 
couple of different ways of handling it and we should discuss this further.


>Have I crushed anyone's enthusiasm? If so, I apologize. ;-)

Not at all! These are good points - thanks for giving it this much thought!

Cheers,

Kal