Re: [Tm4j-developers] Branching TM4J

[<xua...@ba...>]

Lars Heuer wrote:
> Hi Xu=C3=A2n,
>
> [...]
>  =20
>>> IMO very difficult if you want to support TMDM.
>>>  =20
>>>      =20
>> My current idea is to support a superset of TMDM and the current TM4J =
as
>> laid out in
>> http://tm4j.cvs.sourceforge.net/*checkout*/tm4j/tm4j/docs/TMDM-support=
=2Ehtml?revision=3D1.1
>> .
>>    =20
>
> One comment against the doc:
>  =20
You are free to change or amend it. :-) (However, a Wiki may or may not
more appropriate for this.)
> [...]
> - topic type (removed in TMDM, replaced by a
>   http://psi.topicmaps.org/iso13250/model/type-instance association)
>
> In XTM 1.0 the type-instance (resp. class-instance) relationship is
> also modelled by an association. Cf.
> <http://www.topicmaps.org/xtm/index.html#desc-class-instance>. TMDM
> does not remove or add something (the PSIs and terminology has been
> changed, though).
>  =20
You are right. :-) I changed the document accordingly.
> 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.
>  =20
Yes. But for me, there is no compelling reason to actually treat these
types of associations specially internally (actually, this made the
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).
>
>
> TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the
> latest TMDM, but IMO it would be useful to keep an eye on the API or
> use the lib and create your own interfaces ontop of it, i.e.
>
>     public interface Occurrence extends org.tmapi.core.Occurrence {
>
>            public void setValue(String value, Locator datatype);
>
>            [...]
>     }
>
> You would support TMAPI natively but your implementation would be
> TMAPI-independent. If the project dies, you can still use your
> interfaces. The only problem I see is the Topic#getReified() method,
> which returns a Set. But an additional Topic#getReifiedObject() or
> something like that should solve it.
>  =20
Yes.

However, I do not see why org.tmapi.core.Topic.getReified() returns a
Set<TopicMapObject>, not a plain TopicMapObject (or null). Allowing more
than one TopicMapObject to be returned violates the very basic topic map
contract of "one topic represents at most one subject". Maybe this
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"
should be launched, but I maybe this would create more resistance, as
there are more users involved, maybe less, because at least someone does
the work which should be done anyway. I do not know. ;-))
> Best regards,
> Lars
>  =20



Lars Heuer wrote:
> [...]
>  =20
>> TMAPI <http://www.tmapi.org/> is not perfect and not aligned to the
>> latest TMDM, but IMO it would be useful to keep an eye on the API or
>>    =20
> [...]
>
> 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.
>  =20
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.*), 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?
> Best regards,
> Lars
>  =20

Thank you,

Xu=C3=A2n. :-)