From:
<xua...@ba...> - 2007-04-10 09:59:45
|
Kal Ahmed wrote: > > As I=E2=80=99m not really one of the active developers on this anymore,= I=E2=80=99ll > just put in my 2p worth and then shut up J > > =20 > > A TM4J 2 (or TM4J-NG ;-) that supports the features you mention would > make sense. However, IMO there is still a very large topic maps > user-base that neither need nor want the new ISO standards so TM4J 2 > would have to sit in parallel with TM4J for a very long time (possibly > forever). > > [...] > > One other thing: to my mind the changes from XTM 1.0 to XTM 2.0 are > significant enough that I would not be too worried about binary/source > compatibility issues if it makes development easier. > In the course of writing the XTM-2.0-reading-support-patch, I found that it not that hard to remain compatible than I expected. The union of the semantics of XTM 1.0 and XTM 2.0/TMDM are basically: * multiple role players per role (removed in TMDM) * occurence type mandatory (added in TMDM, can be simulated by a "default" occurence type) * association type mandatory (added in TMDM, can be simulated by a "default" association type) * role type mandatory (added in TMDM, can be simulated by a "default" role type) * name type optional (added in TMDM, is simulated by a "default" name type) That basically means that a TM4J 2.0 just needs to support TMDM plus multiple role players per role to both support TMDM and support XTM 1.0 in a fully backward compatible manner. As TM4J 0.9 already supports multiple role players per role, that support just might be kept in TM4J 2.0. (In case one wants to export into a TMDM data format (XTM 2.0, upcoming CTM), these "special roles with multiple players" can be "normalized" into multiple roles with single players each.) Thus, I think now that caring for compatibility outweighs faster development of new features, as it is no point in developing an open source project which has no user base (and thus a very thin developer base). Also, this way, old applications can benefit from new features (like XTM 2.0 and CTM import|export support). Thus, I would want to try to keep TM4J 2 as compatible as possible. Thus, I would prefer option 1. (Change the current TM4J CVS version to include these features.) This also would lessen the load on project admins, as there would not be two competing but understaffed TM4J development versions. > > =20 > > Cheers > > =20 > > Kal > ciao, Xu=C3=A2n. > > =20 > > *From:* tm4...@li... > [mailto:tm4...@li...] *On Behalf Of > *Xu=C3=A2n Baldauf > *Sent:* 06 April 2007 13:51 > *To:* tm4...@li... > *Subject:* [Tm4j-developers] Forking a new development branch > (anticipatingTM4J 2.0) > > =20 > > Hello, > > the current TM4J is becoming increasingly outdated. Much work needs to > be done: > > 1. support the current TMDM ( > http://www.isotopicmaps.org/sam/sam-model/2006-06-18/ ) > > 2. support the current XTM 2.0 ( > http://www.isotopicmaps.org/sam/sam-xtm/2006-06-19/ ) > > 3. support Java 1.5 style (at least, Java 1.6 is already released > now) > > To do this, significant changes are necessary, which probably are not > backwards compatible. As I do not expect every old TM4J-application to > be adapted, I suggest opening a new development branch. The old branch > can be advanced to a version 1.0 (probably without the above > features), but the new branch should result in a TM4J 2.0 with the > above features. I think that it is possible to keep a TM4J 2.0 binary > compatible and source compatible (albeit with compiler warnings) with > TM4J 0.9.8-applicatons, however, for my part of development, > compatibility would not be a major concern. > > For me, there seem to be 3 options: > > 1. Change the current TM4J CVS version to include these features. > > 2. Fork a new branch of the current TM4J CVS version within the > current CVS repository to include these features in this new branch. > > 3. Fork a new branch of the current TM4J CVS version outside of > the current CVS repository to include these features in this new branch= =2E > > I really do not like option 3 (as this would decrease the already low > (at least quiet) userbase and the probability of other people > cooperatively improving on it as well). However, for option 1 or 2, I > need your approval. > > What do you think? > > ciao, > Xu=C3=A2n. > |