tm4j-developers

[Tm4j-developers] Branching TM4J

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

Hello developers,

as I'd like to enhance TM4J with new features (which might imply
significant changes) and as I assume that there is a significant
userbase building on the last current release (which is TM4J 0.9.7 from
more than 2=C2=BD years ago), it is time to create a "stable" branch para=
llel
to the unstable branch. My understanding is as follows:

    * stable branch "TM4J_1_x":
          o Polishing goes on here.
          o Keep source-level compatibility, binary-level compatibility
            to TM4J 0.9.7.
          o Keep requirements-level compatibility to TM4J 0.9.7. (For
            example, do not require a new Java version.)
          o Fix bugs in a compatible way.
          o Get really stable.
          o Be comparably conservative.
    * unstable branch "MAIN":
          o Development goes on here.
          o No hard requirement to keep compatibility (although
            API-level compatibility should be kept as well as possible).
          o New requirements: Java 1.5
          o Fix bugs "the right way"=E2=84=A2.
          o No need to be stable.
          o Be innovative, not conservative.

Having said that, I hope that most of the current TM4J 0.9.7 users will
switch to the unstable branch in the long term, when the features of the
unstable branch at some day outweigh the risks and efforts attached to
switching.

As a little goodie, the rudimentary XTM 2.0 reading support goes into
both branches.

ciao,
Xu=C3=A2n.

Re: [Tm4j-developers] Branching TM4J

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

Hi Xuân,

[...]
> as I'd like to enhance TM4J with new features (which might imply
> significant changes) and as I assume that there is a significant
> userbase building on the last current release (which is TM4J 0.9.7 from
> more than 2½ years ago), it is time to create a "stable" branch parallel
> to the unstable branch. My understanding is as follows:

I prepared a 0.9.x release with which fixes several bugs.
C.f. <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/RELEASE.txt?view=markup>

Someone with admin rights (Murray?) should prepare a release IMO.

The last official release sucks.

[...]
>     * unstable branch "MAIN":
>           o No hard requirement to keep compatibility (although
>             API-level compatibility should be kept as well as possible).

IMO very difficult if you want to support TMDM.

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

Re: [Tm4j-developers] Branching TM4J

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

Hi Xuân,

[...]
>> IMO very difficult if you want to support TMDM.
>>   
> 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.html?revision=1.1
> .

One comment against the doc:

[...]
- 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).

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.



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.

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

Re: [Tm4j-developers] Branching TM4J

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

[...]
> 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
[...]

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.

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

Re: [Tm4j-developers] Branching TM4J

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

Lars Heuer wrote:
> Hi Xu=C3=A2n,
>
> [...]
>  =20
>> as I'd like to enhance TM4J with new features (which might imply
>> significant changes) and as I assume that there is a significant
>> userbase building on the last current release (which is TM4J 0.9.7 fro=
m
>> more than 2=C2=BD years ago), it is time to create a "stable" branch p=
arallel
>> to the unstable branch. My understanding is as follows:
>>    =20
>
> I prepared a 0.9.x release with which fixes several bugs.
> C.f. <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/RELEASE.txt?view=3Dmark=
up>
>  =20
I'm sorry, you are right. I judged from the "News" page (
http://sourceforge.net/news/?group_id=3D27895 ) which currently shows
"TM4J 0.9.7 Released" as the latest announcement.
<http://sourceforge.net/forum/forum.php?forum_id=3D412950>
> Someone with admin rights (Murray?) should prepare a release IMO.
>
> The last official release sucks.
>
> [...]
>  =20
>>     * unstable branch "MAIN":
>>           o No hard requirement to keep compatibility (although
>>             API-level compatibility should be kept as well as possible=
).
>>    =20
>
> IMO very difficult if you want to support TMDM.
>  =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.ht=
ml?revision=3D1.1
=2E

Maybe this proves to be infeasible, maybe not. I'm still somewhat
optimistic. :-) But maybe the additional effort is worth it because
applications using TM4J may get a smooth transition (increasing
development efforts here to decrease development efforts at the
applications).
> Best regards,
> Lars
>  =20

ciao,
Xu=C3=A2n.

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. :-)

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