Re: [Tm4j-developers] Branching TM4J

[Lars H. <he...@se...>]

Hi Xuân,

[...]
>> The topic type was/is used as simplification of a
>> type-instance association (in the unconstrained scope). IMO it is
>> useful from the API-user perspective.
>>   
> Yes. But for me, there is no compelling reason to actually treat these
> types of associations specially internally (actually, this made the

Well, you could add associations behind the scenes. It is an
implementation matter.

> implementation of some of my TM4J applications harder). This increases
> code complexity. And, these types of associations are missing as
> ordinary associations (which is a bug then, not a feature of XTM 1.0, as
> you pointed out).

Well, "bug" depends on the perspective. :) As long as it is well
documentated it is not a bug, IMO. AFAIK, nearly all Topic Maps
engines support this "bug".
It is easy to translate the "types" Set into associations and vice
versa.


[...]
> However, I do not see why org.tmapi.core.Topic.getReified() returns a
> Set<TopicMapObject>, not a plain TopicMapObject (or null). Allowing more

Historical reasons. :) And the reification mechanism has been changed
between XTM and TMDM.

[...]
> should be fixed in TMAPI, (Maybe along with aligning TMAPI to the latest
> TMDM and to Java 1.5 as well. Maybe a kind of parallel project "TMAPI 2"

ACK. But I am afraid that the TMAPI group is too lazy / busy to make a
change. If you look into the TMAPI bug tracker, you'll see, that there
are several feature requests which address these issues.

[...]
>> If you look into the classes located in the org.tm4j.tmapi package
>> <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/tmapi/core/>
>> you'll see some of the problems with the current TM4J-API and a
>> TMDM-alike API.
>>   
> After a short glance (maybe too short), I see just lots of wrapping work
> (where I ask myself why does org.tm4j.topicmap.* not just extend
> org.tmapi.core.*),

Again, historical reasons. :) The TM4J API is older than TMAPI. And it
was planned that TM4J should implement the TMAPI interfaces directly
after 1.x, I guess.

>  I do not currently see specific problems (however, my
> glance may not have been thorough enough). Would you mind pointing out a
> serious (e.g. hard to fix) problem of the current TM4J-API?

Hmmm.... . Without looking into the code, the handling variants and
members are a lot different and if I remember right, there are some
situations where a translation of the TM4J API into a TMDM-alike API
is not possible. Sorry. Not very concrete... ;) Maybe you want to look
into the code again and search for situations where a runtime
exception is thrown (i.e. TMAPIRuntimeException).

Additionally, TM4J is currently not datatype-aware (and TMAPI is also
datatype-blind), you have to enhance the Occurrence / Variant or
DataObject interfaces.

All in all, a lot of work... . I am not sure if it is valueable to
keep a TMDM/XTM 2.0 branch backwards compatible. I'd start with new
interfaces / a new API (maybe an API which enhances the TMAPI
interfaces).

Best regards,
Lars
-- 
http://www.semagia.com