You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(22) |
Jul
(4) |
Aug
(9) |
Sep
(6) |
Oct
(5) |
Nov
(15) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(4) |
Feb
(10) |
Mar
(12) |
Apr
(16) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(9) |
Sep
(3) |
Oct
(17) |
Nov
(17) |
Dec
(6) |
2003 |
Jan
(12) |
Feb
(15) |
Mar
(25) |
Apr
(20) |
May
(8) |
Jun
(3) |
Jul
(21) |
Aug
(10) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(6) |
2004 |
Jan
(5) |
Feb
(16) |
Mar
(34) |
Apr
(26) |
May
(20) |
Jun
(58) |
Jul
(76) |
Aug
(51) |
Sep
(40) |
Oct
(16) |
Nov
(7) |
Dec
(6) |
2005 |
Jan
(10) |
Feb
(1) |
Mar
(17) |
Apr
(8) |
May
(11) |
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(6) |
Oct
(10) |
Nov
(14) |
Dec
(9) |
2006 |
Jan
(11) |
Feb
(22) |
Mar
(17) |
Apr
(1) |
May
(15) |
Jun
(9) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2008 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(8) |
May
(12) |
Jun
(9) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Conal T. <con...@vu...> - 2008-04-15 02:45:37
|
On Sat, 2008-04-05 at 23:58 +1300, Xuân Baldauf wrote: > What the author of this expression presumably meant, is "is this topic > object in master mode?", and thus the author should have refactored > all occurrences of this expression to "t.isInMasterMode()" (or > "t.isBaseTopic()" when retaining the nomenclature). However, he did > not, and refactoring "t.getID().equals(t.getBaseTopic().getID())" into > "t.equalsByID(t.getBaseTopic())" was one step into this direction. I understand your analysis, but I don't see why, on the basis of that analysis, you did not just refactor it to "t.isBaseTopic()"? Or did you make this analysis after the earlier refactoring to use "t.equalsByID(t.getBaseTopic())"? -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: Suhas R. M. <suh...@or...> - 2008-04-14 23:42:45
|
Thanks Kal for the details. I am able to generate a public key for SSH connectivity but find no place on SourceForge.net to upload it. Do you have any idea how and where I can upload the key? Also, I get the following error when running the command in the mail below. Any thoughts? D:\Projects\zPractice\tm4j>cvs -z3 -d:pserver:ano...@tm...:/cvsroot/tm4j co -P tm4j connect to tm4j.cvs.sourceforge.net:2401 failed: A socket operation was attempted to an unreachable host. Thanks, Suhas. Kal Ahmed wrote: > Hi Suhas, > > I would definitely advise getting the source from CVS. There have been > quite a few bug fixes and changes that have not yet been released. > > On a Windows machine the easiest way to get access to CVS would be to > install TortoiseCVS (www.tortoisecvs.org) and then follow the > instructions on the SourceForge site at > http://sourceforge.net/cvs/?group_id=27895. The main module to get is > the tm4j module, so your actual CVS checkout string would be > > cvs -z3 -d:pserver:ano...@tm...:/cvsroot/tm4j co -P tm4j > > Hope this helps! > > Cheers > > Kal |
From: Kal A. <tec...@gm...> - 2008-04-12 11:02:14
|
Hi Suhas, I would definitely advise getting the source from CVS. There have been quite a few bug fixes and changes that have not yet been released. On a Windows machine the easiest way to get access to CVS would be to install TortoiseCVS (www.tortoisecvs.org) and then follow the instructions on the SourceForge site at http://sourceforge.net/cvs/?group_id=27895. The main module to get is the tm4j module, so your actual CVS checkout string would be cvs -z3 -d:pserver:ano...@tm...:/cvsroot/tm4j co -P tm4j Hope this helps! Cheers Kal On Thu, Apr 10, 2008 at 10:46 PM, Suhas R. Mehta <suh...@or...> wrote: > > No issues, Kal and I certainly appreciate your response and help. Here's an update. > > I'd downloaded the code from TM4J 0.9.7. I tried compiling the code via the command line (using build.bat). Here I get the following failure error. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > BUILD FAILED > D:\Projects\apache-ant-1.7.0\build.xml:1105: The following error occurred while executing this line: > D:\Projects\apache-ant-1.7.0\build.xml:911: We cannot build the test jar unless JUnit is present, > as JUnit is needed to compile the test classes. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Later, I tried compiling JDeveloper where it threw several errors including EclipseProjectTest.java. > > Finally, on Eclipse v3.3.2 I was able to resolve all the issues by excluding the org.tm4j.ant.test package from Eclipse. I'm still unsure as to why would it fail to compile EclipseProjectTest.java. But I guess, for now, it wouldn't hurt to not have these test classes. I'm currently working on understanding the code going through the developer guide. > > You mention that I can get code from CVS. How do I get access to the CVS repository? > > Thanks, > Suhas. > > > > > Kal Ahmed wrote: > Hi Suhas, > > Sorry for the delay in replying. > > I've just grabbed a complete fresh copy of the source tree from CVS and built it with the build.bat script on my Windows box. The build went through without a problem. The file that is reported as missing is in the source tree (in the directory src/org/tm4j/ant/test/). Can you check if that file is present on your machine (if not it might just be a CVS glitch and you might want to try doing a CVS update or event checking out the tree again), if its not a missing file issue perhaps you could tell us a bit more about how you are building the project (command-line ? JDeveloper?) and anything else you think might help us get to the bottom of the compilation problem > > Cheers > > Kal > > > On Tue, Apr 8, 2008 at 6:30 PM, Suhas R. Mehta <suh...@or...> wrote: > > > > > Hi, > > > > I've been trying to setup the TM4J development env. and am having some difficulties in getting the source code compiled. > > > > I'm seeing several compilation errors but looks like they all stem from: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Severity and Description Path Resource Location Creation Time Id > > BuildFileTest cannot be resolved to a type TM4J/src/org/tm4j/ant/test EclipseProjectTest.java line 39 1207171035414 187126 > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > I'm unable to find BuildFileTest class in ant.jar that came packaged with TM4J. I also tried compiling "apache-ant-1.7.0" project but that too didn't create the class file. > > > > Is there any particular ordering I should follow when including the jar files in my project? Is there any setup document for someone like me to get started in setting up the dev. env. as well as running the tests. > > > > When you have a chance, would you please respond to this email and help me out. > > > > Thanks, > > Suhas. > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > > Register now and save $200. Hurry, offer ends at 11:59 p.m., > > Monday, April 7! Use priority code J8TLD2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > > _______________________________________________ > > Tm4j-users mailing list > > Tm4...@li... > > https://lists.sourceforge.net/lists/listinfo/tm4j-users > > > > > > |
From: Suhas R. M. <suh...@or...> - 2008-04-10 21:48:38
|
No issues, Kal and I certainly appreciate your response and help. Here's an update. I'd downloaded the code from TM4J 0.9.7 <http://tm4j.org/downloads.html>. I tried compiling the code via the command line (using build.bat). Here I get the following failure error. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= BUILD FAILED D:\Projects\apache-ant-1.7.0\build.xml:1105: The following error occurred while executing this line: D:\Projects\apache-ant-1.7.0\build.xml:911: We cannot build the test jar unless JUnit is present, as JUnit is needed to compile the test classes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Later, I tried compiling JDeveloper where it threw several errors including EclipseProjectTest.java. Finally, on Eclipse v3.3.2 I was able to resolve all the issues by excluding the org.tm4j.ant.test package from Eclipse. I'm still unsure as to why would it fail to compile EclipseProjectTest.java. But I guess, for now, it wouldn't hurt to not have these test classes. I'm currently working on understanding the code going through the developer guide. You mention that I can get code from CVS. How do I get access to the CVS repository? Thanks, Suhas. Kal Ahmed wrote: > Hi Suhas, > > Sorry for the delay in replying. > > I've just grabbed a complete fresh copy of the source tree from CVS > and built it with the build.bat script on my Windows box. The build > went through without a problem. The file that is reported as missing > is in the source tree (in the directory src/org/tm4j/ant/test/). Can > you check if that file is present on your machine (if not it might > just be a CVS glitch and you might want to try doing a CVS update or > event checking out the tree again), if its not a missing file issue > perhaps you could tell us a bit more about how you are building the > project (command-line ? JDeveloper?) and anything else you think might > help us get to the bottom of the compilation problem > > Cheers > > Kal > > On Tue, Apr 8, 2008 at 6:30 PM, Suhas R. Mehta <suh...@or... > <mailto:suh...@or...>> wrote: > > Hi, > > I've been trying to setup the TM4J development env. and am having > some difficulties in getting the source code compiled. > > I'm seeing several compilation errors but looks like they all stem > from: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Severity and Description Path Resource Location > Creation Time Id > BuildFileTest cannot be resolved to a type > TM4J/src/org/tm4j/ant/test EclipseProjectTest.java line > 39 1207171035414 187126 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > I'm unable to find BuildFileTest class in ant.jar that came > packaged with TM4J. I also tried compiling "*apache-ant-1.7.0*" > project but that too didn't create the class file. > > Is there any particular ordering I should follow when including > the jar files in my project? Is there any setup document for > someone like me to get started in setting up the dev. env. as well > as running the tests. > > When you have a chance, would you please respond to this email and > help me out. > > Thanks, > Suhas. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Tm4j-users mailing list > Tm4...@li... > <mailto:Tm4...@li...> > https://lists.sourceforge.net/lists/listinfo/tm4j-users > > |
From: Kal A. <tec...@gm...> - 2008-04-10 19:41:30
|
Hi Suhas, Sorry for the delay in replying. I've just grabbed a complete fresh copy of the source tree from CVS and built it with the build.bat script on my Windows box. The build went through without a problem. The file that is reported as missing is in the source tree (in the directory src/org/tm4j/ant/test/). Can you check if that file is present on your machine (if not it might just be a CVS glitch and you might want to try doing a CVS update or event checking out the tree again), if its not a missing file issue perhaps you could tell us a bit more about how you are building the project (command-line ? JDeveloper?) and anything else you think might help us get to the bottom of the compilation problem Cheers Kal On Tue, Apr 8, 2008 at 6:30 PM, Suhas R. Mehta <suh...@or...> wrote: > Hi, > > I've been trying to setup the TM4J development env. and am having some > difficulties in getting the source code compiled. > > I'm seeing several compilation errors but looks like they all stem from: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Severity and Description Path Resource Location Creation > Time Id > BuildFileTest cannot be resolved to a type > TM4J/src/org/tm4j/ant/test EclipseProjectTest.java line 39 > 1207171035414 187126 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > I'm unable to find BuildFileTest class in ant.jar that came packaged with > TM4J. I also tried compiling "*apache-ant-1.7.0*" project but that too > didn't create the class file. > > Is there any particular ordering I should follow when including the jar > files in my project? Is there any setup document for someone like me to get > started in setting up the dev. env. as well as running the tests. > > When you have a chance, would you please respond to this email and help me > out. > > Thanks, > Suhas. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Tm4j-users mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-users > > |
From: Suhas R. M. <suh...@or...> - 2008-04-08 17:33:53
|
Hi, I've been trying to setup the TM4J development env. and am having some difficulties in getting the source code compiled. I'm seeing several compilation errors but looks like they all stem from: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Severity and Description Path Resource Location Creation Time Id BuildFileTest cannot be resolved to a type TM4J/src/org/tm4j/ant/test EclipseProjectTest.java line 39 1207171035414 187126 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I'm unable to find BuildFileTest class in ant.jar that came packaged with TM4J. I also tried compiling "*apache-ant-1.7.0*" project but that too didn't create the class file. Is there any particular ordering I should follow when including the jar files in my project? Is there any setup document for someone like me to get started in setting up the dev. env. as well as running the tests. When you have a chance, would you please respond to this email and help me out. Thanks, Suhas. |
From: Xuân B. <xua...@ba...> - 2008-04-05 12:08:27
|
Conal Tuohy wrote: > Hi Xuan > > I can see that you have defined a new set of interfaces for the new > data model. The point I'm trying to make is that I think you should > have done that WITHOUT ALSO making (any) change to the existing > interfaces for the old data model. > > You say you've only made this one change, and it's true it's not in > itself a big change. I would be quite happy for this method to exist > (though I'd prefer it to be called equals() as I said earlier), but > more importantly, the fact that you added the method at all is > indicative of a design approach you have taken which I think is > mistaken, and which has actually caused me some problems. > > You agreed with me that the data models are incompatible, yet your > change to the TopicMapObject interface is precisely for the purpose of > establishing (limited) compatibility. This still doesn't make sense to > me: it seems to me that if the 2 models are really incompatible, then > there is no need at all to change the old interface. So I think > there's a contradiction in what you have said. > > It appears to me that the change to the interface was to make it > convenient to use common code to process both XTM 1 and XTM 2. If you mean the equalsByID() change, then, no, this change was independent of the XTM 2 reading support. > Specifically, I'm referring to the revisions to > org.tm4j.topicmap.utils in which you introduced some XTM 2 support: > > http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMParser.java?r1=1.19&r2=1.20 > <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMParser.java?r1=1.19&r2=1.20> > http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMBuilder.java?r1=1.72&r2=1.73 > <http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMBuilder.java?r1=1.72&r2=1.73> > > These classes used to parse XTM 1 and build an XTM1-flavoured topic > map graph. > > If I understand it correctly, it still builds a topic map conforming > to the old model (i.e. not the TMDM), but you have changed it so that > it will parse documents which are either: > > 1) XTM 1; > 2) a subset of (?) XTM 2; or > 3) some kind of hybrid of XTM 1 and 2; > > Dealing with those in order: > > 1) The XTM 1 support is currently broken in HEAD because of a change > to the handling of xtm:member/xtm:topicRef (there's even a comment in > the code to this effect, saying that it causes problems but "is > correct" - something I don't understand at all). Well, that's a bug. Maybe there is a testcase available? > > 2) I don't understand how you are planning to finish this; how will > you handle the other discrepancies between the 2 data model? How would > you handle typed names for example? > > 3) I don't think is desirable at all. IMHO the parser/builder would be > much improved by adding validation to ensure that the markup conformed > to the correct schema. Allowing for a mixture of the 2 is a step away > from that. > > In any case I don't think it's a good idea to mix up the 2 markup > languages (XTM 1 and 2) in the same parser. In my opinion you should > create a distinct XTM2Parser, and it should use an XTM2Builder to > build a TMDM graph. Yes, I agree one should build a nice XTM2 parser because the current parser actually parses a subset of the union of the XTM1 and XTM2 languages. However, building a separate XTM2 parser is a considerable effort, and the current XTM2 support is a hack (that is, it works for what it was needed, it was written relatively quickly using existing infrastructure, but it also allows more than should be allowed). Allowing more than it should is not really a problem, as there are external XML validators available which can reject everything which is a real superset of either XTM1 or XTM2. Breaking correct code is a problem, though (but one which can be solved). If someone finds time to write a clean XTM2 parser - great. But XTM2 is not that far from XTM1 away, so for supporting typed names, a XTM1+2 parser could peek and poke through the wrapper for this special case. That is not best design, however, given that XTM1 and XTM2 are fixed standards and there is only a small list of differences between them, it is probably considerably more economic to make a current XTM1 parser XTM2 aware than to build a new XTM2 parser from scratch. > At the moment we have a parser/builder which does not fully handle > either XTM 1 or 2, which is regrettable. > >> Additionally, I considered (and still consider) this API "public, but >> extendable" (although I do not intend any further changes). >> > > Well - my perspective is different. My view is that the old interface > is adequate for XTM 1 and should not in general be changed (certainly > not without consensus). Just as the XTM 1 standard still exists and > remains stable these last several years, so the interface should > remain stable as well. Naturally XTM 2 is entitled to exist and to > formally "supercede" XTM 1, but it does not actually modify XTM 1, and > neither, IMHO, should TMDM support in TM4J2 require changes to the > XTM1 parts of TM4J. It should not, but TM4J1 (and the Java language itself, too) are not that modular that TM4J2 support can just be "merged in" like you can "merge in" a topic map. TMDM support in TM4J2 is not intended to be a wholly separate TM engine, it should leverage all the existing TM4J1 applications, else I would have made the TMDM support in TM4J2 being a separate open source project right from the start. So if two systems are to connect, I think it is reasonable to build bridges at both ends (i.e. XTM1 parts as one end and and the TMDM support as the other end) where it makes sense most. > >> But even >> though I do know now that there is external software implementing the >> API, I still think an approach like it is done with the Linux kernel is >> appropriate: >> >> 1. What is in the kernel gets refactored appropriately by those who >> do the refacto ring. >> > yes >> 2. What is outside but implements an inside interface has to be >> updated by the outside maintainers in order to mirror the kernel >> develop ment. >> > yes >> 3. Development freeze (=stopping changing APIs) over extended periods >> of time is unaccept able. >> > Here I disagree. I believe that certain APIs should indeed be frozen > over extended periods. > > These are the APIs that correspond closely to e.g. the standard markup > languages and data models. > > At the very least, when these public APIs are changed they MUST be > announced. I agree. As I said, I had a closed-world assumption (I expected that the only recipients of such an announcement would be the 3 existing backends, and in this case it was easier and faster to just change them). >> 4. Who wants to be really conservative and not go the way of being >> up-to-date (both regarding breaking code and regarding reaping the >> fruits of the development) may stick with an old ver sion. >> > I believe that being conservative has its place. I am not at all > opposed to adding new APIs, but changing existing APIs should not to > be done lightly IMHO. > > There is nothing stopping you from adding new APIs, and adding XTM 2 > support - the only problem is that you have disrupted the XTM 1 > support in the process. I am currently working from an old revision > becaue of bugs in XTM 1 support in the current version. This is why > agreement of the other committers to adding XTM 2 support was > conditional on that change being made in a branch, and kept separate > from the XTM 1-related code. Particularly for people who are running > TM4J in production, it's important to be able to have the ability to > fix bugs, while otherwise retaining stability. Our project at NZETC is > heavily reliant on XTM 1, with little or no prospect of adopting XTM > 2. For us, XTM 2 development is significantly less important (at least > in the short term) than retaining stability of the XTM 1-compatible > code base. > > So this is why I believe we must now create a branch (based on a > revision prior to the introduction of XTM 2 code). We can call the > branch "TM4J_1" and we can keep all XTM 2 features out of it. Now, for what it is worth, I have created such a branch long ago, and I have called it "TM4J_1_x", very similar to what you propose. However, I created this branch deliberately _after_ introducing the XTM2 reading code (which, however, only reads XTM2 files into the XTM1 data model), because I felt it would benefit TM4J1 users by allowing them to remain longer on TM4J1 before switching to TM4J2 while the rest of the world starts emitting XTM2 documents, similar to the .odt support in OpenOffice 1.1.5 (.odt is the file format of OpenOffice 2). Of course, I was not aware of that XTM1 topicRef bug. Do you think if I fix this bug (both in the trunk and in the "TM4J_1_x" branch), then this "TM4J_1_x" branch reflects your intended "TM4J_1" branch enough? If not, please feel free to create another branch before the introduction of XTM2 reading code. > This branch can then be developed until the release of TM4J 1.0. In > the meantime, Xuan, you can continue your work on XTM 2 in the trunk. :-) > >> Additionally, specific to TM4J, there is low to virtually no activity on >> the project in the last 12 months (at least when I exclude commits by >> myself), so even for major (API) changes, there is not really any reply >> expected. Thus, it is quite unreasonable to ask and wait for no reply. >> Thus, I think, if there is any progress to be expected at all, the >> burden of disagreeing (like writing e-mails and debating pros and cons) >> should be on those being otherwise passive (i.e. by default every change >> is allowed unless challenged, not by default every change is denied, >> unless allowed). >> > I disagree strongly with this. Disruptive changes to the code should > be discussed in public, or at least proposed publicly, so that they > CAN be discussed. I think there are great advantages to following such > a collaborative process. > > Anyway ... consider your revision "challenged". I am not just going to > revert your changes but I do expect that we attempt to reach to a > consensus now. > > I want to come to an arrangement in which the TM4J_1 branch is > established purely for XTM 1.0, and the trunk is used for developing > XTM 2.0 support in a way which does not mix up XTM 1 and XTM 2. As I > explained earlier, my primary interest is in XTM 1.0 (because of my > other software which produces XTM 1), and hence I don't think I'll be > able to do much on the XTM 2 branch, but all the same I still have an > opinion on how it should be done, and I don't want to be left out of > the loop :-) I think, with your branching suggestion, we are well at such an agreement (or at least pretty near to it, as I still think that it sometimes makes sense to change the TM4J1-legacy within TM4J2 to integrate with the TMDM backend). What do you think? (It is a little bit a shame that the code is not (and presumably never has been) in the state where all the testcases succeeded. If so, we could switch to test-driven development where nearly every change is okay unless a testcase fails.) > >> I'd like to ask you to make your API implementation publicly writable >> (e.g. import it into the TM4J project under some open source licenses), >> then bad surprises like a need to adapt to new versions can be avoided. >> > > Yeah - I will be contributing the sqlprovider code when it is > substantially more complete. At present it is still missing quite a > few bits - a number of TopicMapUtils methods, and most of the indexing > interface. It's probably still a couple of months off, at least. Maybe you want to share it anyways, even if it is not complete. :-) This is okay in the CVS HEAD (not in releases, though), and it would give other people the opportunity to do some parts of the work needed. > > -- > Conal Tuohy > New Zealand Electronic Text Centre > www.nzetc.org <http://www.nzetc.org> > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers > |
From: Xuân B. <xua...@ba...> - 2008-04-05 10:59:58
|
Conal Tuohy wrote: > On Tue, 2008-03-11 at 22:36 +1300, Xuân Baldauf wrote: > >> Conal Tuohy wrote: >> >>> On Tue, 2008-03-11 at 16:39 +1300, Xuân Baldauf wrote: >>> >>> >>> >>>> If I remember correctly, I think >>>> http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/TopicMapObjectImpl.java?revision=1.5&amp;view=markup#l_126 is the reason for equalsByID(). This provider is a bridge between XML Topic Maps (in the style of TM4J 0.9.x) and TMDM (in the style of TM4J2). TMDM in general, and the TM4J2-implementation of TMDM in particular, does not require a TopicMapObject to have exactly one ID. Consequently, getID() is not defined, strictly speaking. If getID() is called anyways, some compatibility magic auto-creates an ID if no ID cannot be found or somehow inferred. However, this is a kludge (as a read-only method has a state-changing behaviour), and should be avoided, especially if the only purpose of calling getID() is comparing whether two TopicMapObjects are equal in some sens >>>> e (which >>>> should be read-only-process in turn). You do not want to have an OutOfMemoryError just because you called getID(). >>>> >>>> >>> Why not just use the equals() method then, Xuan? >>> >>> >> Personally, I do not care about the name. However, care should be >> taken because we have multiple notions of equality in topic maps and >> in TM4J (like: Are two Topic objects, which are merged, equal? Are two >> Topic objects, which are not yet merged, but should be merged, >> equal?). >> >>> Isn't that the purpose of equalsByID()? >>> >>> >> Maybe, maybe not. The purpose of equalsByID() is "If I would take the >> IDs of the two topic map items involved and compare them, would that >> comparison yield true?". >> > > What does "equals by ID" mean in the case of TMDM topic maps in which > objects may have multiple ids? Would the comparison require that the two > topic map items had at least one item identifier in common? > I have been digging into this (again). When looking at the call sites where equalsByID() is used apart from being used internally to a backend, there is only http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/TopicMapWalker.java?r1=1.24&r2=1.25 . In this case, the walk() method first walks over all topic objects and then over all association objects. Over all topic objects? No. It does not walk over topic objects which are in "slave" mode when being merged. That needs a little bit more elaboration. In TM4J1, topic objects just exist initially. However, when two topic objects are merged, they still exist independently as two distinct Java objects. However (unless specified explicitly by the user), after merging, the two topic objects are somehow connected internally and behave like one merged topic. However, in one respect they cannot behave like one merged topic, and this is regarding the pointers to them, the pointers are still not equal. So if somebody is encountering both pointers (i.e. by walking over the list of topic objects of a topic map object or by other means), the topic will be walked over twice, which should not happen, because two topics are merged into one. Now, in TM4J1, the "somehow connected internally" between two or more topic objects is implemented by electing one master topic object, all the other ones being slave topic objects. For example, in the memory backend, the slave topic objects have the "m_baseTopic" field set to point to the master topic object, while the master topic object has the "m_mergedTopics" field set to an ArrayList of slave topic objects. The topic objects in the slave mode and topic objects in the master mode (should) behave identical, however, apparently, they differ with respect to the method getID(). Thus, the expression "t.getID().equals(t.getBaseTopic().getID())" (which was scattered all over TM4J1 before I changed this a little bit) evaluates only to "true" if "t" is actually the master mode topic object of a merged topic. (Topic objects which were not merged with any other topic object are in master mode by default.) Because there is only one master mode topic object per merged topic, using this expression, it was tried to ensure that all topics, being merged or not, are walked over only once. What the author of this expression presumably meant, is "is this topic object in master mode?", and thus the author should have refactored all occurrences of this expression to "t.isInMasterMode()" (or "t.isBaseTopic()" when retaining the nomenclature). However, he did not, and refactoring "t.getID().equals(t.getBaseTopic().getID())" into "t.equalsByID(t.getBaseTopic())" was one step into this direction. For the way TMDM topic maps are implemented in TM4J2, there is no notion at all of a master mode or a slave mode a topic object can be in. In the TMDM implementation, topic objects are either always in slave mode (then they are instance of class BasicTopic, see http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/basic/ ), or they are always in master mode (then they are currently instance of class MergedTopic, see http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/merged/ ). There is a distinction of where you apply the changes (in BasicTopic) and where you see the consequences (in MergedTopic). Why this is so, is a different, well, topic (but I'm happy to explain that). For what is needed here, both BasicTopic and MergedTopic are wrapped by org.tm4j.topicmap.tmdm.tm4j1.TopicImpl to an TM4J1-compatible interface, and the method tm.getTopicsIterator() called by method TopicMapWalker.walk() always yields (in the TMDM wrapping layer case) a list of these TopicImpl objects, where merged topic objects do not appear twice. Thus, "t.equalsByID(t.getBaseTopic())" needs to yield "true" in every case when it is called at this call site, and, indeed, it does, as TopicImpl.getBaseTopic() always returns "this" (see http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/TopicImpl.java?revision=1.10&view=markup#l_553 ). > >> Whether this definition happens to be equivalent or not to other >> definitions of equality: I do not know, and this is out of the scope >> of equalsByID(), and this is because I chose "equalsByID()" as name >> and not "equals()". >> > > OK. > > I think it would be good to actually determine the existing semantics of > equals() (in the existing providers), and if this is compatible with the > requirements of equalsByID() (or can easily be made so), to use the name > "equals" rather than "equalsByID". > Having the analysis of above in mind, I'd suggest doing the refactoring into the direction of Topic.isInMasterMode() (or Topic.isBaseTopic() respectively). Then we can get rid of equalsByID() in the interface. (However, we can go even further by defining TopicMap.getMasterModeTopicsIterator(), that is, this method's contract guarantees that no slave topics (i.e. "double topics") are returned. This is what the TMDM wrapper backend can provide (and other backends can provide, too, by using the legacy method TopicMap.getTopicsIterator() and filtering out any slave topic object), while Topic.isInMasterMode() is not meaningful at all for the TMDM wrapper backend.) > >>> Or is there some difference in semantics between equals() and >>> equalsByID()? >>> >>> >> Depends on the intended semantics of equals() and, as they do not seem >> to be defined currently (like equals() is not overriden), a difference >> between equals() and equalsByID() is also not defined. >> >> ciao, >> Xuân. >> >> P.S.: If you happen to be in Auckland in the next months, then just >> drop me a note, then we can meet in person. :-) >> > > I don't get up there much, but you never know; I might well be. When are > you planning to be in Auckland? > From between now and the next 3 month (I'm already there). ciao, Xuân. |
From: Conal T. <con...@vu...> - 2008-03-13 02:20:14
|
Hi Xuan I can see that you have defined a new set of interfaces for the new data model. The point I'm trying to make is that I think you should have done that WITHOUT ALSO making (any) change to the existing interfaces for the old data model. You say you've only made this one change, and it's true it's not in itself a big change. I would be quite happy for this method to exist (though I'd prefer it to be called equals() as I said earlier), but more importantly, the fact that you added the method at all is indicative of a design approach you have taken which I think is mistaken, and which has actually caused me some problems. You agreed with me that the data models are incompatible, yet your change to the TopicMapObject interface is precisely for the purpose of establishing (limited) compatibility. This still doesn't make sense to me: it seems to me that if the 2 models are really incompatible, then there is no need at all to change the old interface. So I think there's a contradiction in what you have said. It appears to me that the change to the interface was to make it convenient to use common code to process both XTM 1 and XTM 2. Specifically, I'm referring to the revisions to org.tm4j.topicmap.utils in which you introduced some XTM 2 support: http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMParser.java?r1=1.19&r2=1.20 http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/utils/XTMBuilder.java?r1=1.72&r2=1.73 These classes used to parse XTM 1 and build an XTM1-flavoured topic map graph. If I understand it correctly, it still builds a topic map conforming to the old model (i.e. not the TMDM), but you have changed it so that it will parse documents which are either: 1) XTM 1; 2) a subset of (?) XTM 2; or 3) some kind of hybrid of XTM 1 and 2; Dealing with those in order: 1) The XTM 1 support is currently broken in HEAD because of a change to the handling of xtm:member/xtm:topicRef (there's even a comment in the code to this effect, saying that it causes problems but "is correct" - something I don't understand at all). 2) I don't understand how you are planning to finish this; how will you handle the other discrepancies between the 2 data model? How would you handle typed names for example? 3) I don't think is desirable at all. IMHO the parser/builder would be much improved by adding validation to ensure that the markup conformed to the correct schema. Allowing for a mixture of the 2 is a step away from that. In any case I don't think it's a good idea to mix up the 2 markup languages (XTM 1 and 2) in the same parser. In my opinion you should create a distinct XTM2Parser, and it should use an XTM2Builder to build a TMDM graph. At the moment we have a parser/builder which does not fully handle either XTM 1 or 2, which is regrettable. > Additionally, I considered (and still consider) this API "public, but > extendable" (although I do not intend any further changes). Well - my perspective is different. My view is that the old interface is adequate for XTM 1 and should not in general be changed (certainly not without consensus). Just as the XTM 1 standard still exists and remains stable these last several years, so the interface should remain stable as well. Naturally XTM 2 is entitled to exist and to formally "supercede" XTM 1, but it does not actually modify XTM 1, and neither, IMHO, should TMDM support in TM4J2 require changes to the XTM1 parts of TM4J. > But even > though I do know now that there is external software implementing the > API, I still think an approach like it is done with the Linux kernel is > appropriate: > > 1. What is in the kernel gets refactored appropriately by those who > do the refactoring. yes > 2. What is outside but implements an inside interface has to be > updated by the outside maintainers in order to mirror the kernel > development. yes > 3. Development freeze (=stopping changing APIs) over extended periods > of time is unacceptable. Here I disagree. I believe that certain APIs should indeed be frozen over extended periods. These are the APIs that correspond closely to e.g. the standard markup languages and data models. At the very least, when these public APIs are changed they MUST be announced. > 4. Who wants to be really conservative and not go the way of being > up-to-date (both regarding breaking code and regarding reaping the > fruits of the development) may stick with an old version. I believe that being conservative has its place. I am not at all opposed to adding new APIs, but changing existing APIs should not to be done lightly IMHO. There is nothing stopping you from adding new APIs, and adding XTM 2 support - the only problem is that you have disrupted the XTM 1 support in the process. I am currently working from an old revision becaue of bugs in XTM 1 support in the current version. This is why agreement of the other committers to adding XTM 2 support was conditional on that change being made in a branch, and kept separate from the XTM 1-related code. Particularly for people who are running TM4J in production, it's important to be able to have the ability to fix bugs, while otherwise retaining stability. Our project at NZETC is heavily reliant on XTM 1, with little or no prospect of adopting XTM 2. For us, XTM 2 development is significantly less important (at least in the short term) than retaining stability of the XTM 1-compatible code base. So this is why I believe we must now create a branch (based on a revision prior to the introduction of XTM 2 code). We can call the branch "TM4J_1" and we can keep all XTM 2 features out of it. This branch can then be developed until the release of TM4J 1.0. In the meantime, Xuan, you can continue your work on XTM 2 in the trunk. > Additionally, specific to TM4J, there is low to virtually no activity on > the project in the last 12 months (at least when I exclude commits by > myself), so even for major (API) changes, there is not really any reply > expected. Thus, it is quite unreasonable to ask and wait for no reply. > Thus, I think, if there is any progress to be expected at all, the > burden of disagreeing (like writing e-mails and debating pros and cons) > should be on those being otherwise passive (i.e. by default every change > is allowed unless challenged, not by default every change is denied, > unless allowed). I disagree strongly with this. Disruptive changes to the code should be discussed in public, or at least proposed publicly, so that they CAN be discussed. I think there are great advantages to following such a collaborative process. Anyway ... consider your revision "challenged". I am not just going to revert your changes but I do expect that we attempt to reach to a consensus now. I want to come to an arrangement in which the TM4J_1 branch is established purely for XTM 1.0, and the trunk is used for developing XTM 2.0 support in a way which does not mix up XTM 1 and XTM 2. As I explained earlier, my primary interest is in XTM 1.0 (because of my other software which produces XTM 1), and hence I don't think I'll be able to do much on the XTM 2 branch, but all the same I still have an opinion on how it should be done, and I don't want to be left out of the loop :-) > I'd like to ask you to make your API implementation publicly writable > (e.g. import it into the TM4J project under some open source licenses), > then bad surprises like a need to adapt to new versions can be avoided. Yeah - I will be contributing the sqlprovider code when it is substantially more complete. At present it is still missing quite a few bits - a number of TopicMapUtils methods, and most of the indexing interface. It's probably still a couple of months off, at least. -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: Conal T. <con...@vu...> - 2008-03-13 00:54:36
|
On Tue, 2008-03-11 at 22:36 +1300, Xuân Baldauf wrote: > Conal Tuohy wrote: > > On Tue, 2008-03-11 at 16:39 +1300, Xuân Baldauf wrote: > > > > > > > If I remember correctly, I think > > > http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/TopicMapObjectImpl.java?revision=1.5&amp;view=markup#l_126 is the reason for equalsByID(). This provider is a bridge between XML Topic Maps (in the style of TM4J 0.9.x) and TMDM (in the style of TM4J2). TMDM in general, and the TM4J2-implementation of TMDM in particular, does not require a TopicMapObject to have exactly one ID. Consequently, getID() is not defined, strictly speaking. If getID() is called anyways, some compatibility magic auto-creates an ID if no ID cannot be found or somehow inferred. However, this is a kludge (as a read-only method has a state-changing behaviour), and should be avoided, especially if the only purpose of calling getID() is comparing whether two TopicMapObjects are equal in some sense (which > > > should be read-only-process in turn). You do not want to have an OutOfMemoryError just because you called getID(). > > > > > > > Why not just use the equals() method then, Xuan? > > > Personally, I do not care about the name. However, care should be > taken because we have multiple notions of equality in topic maps and > in TM4J (like: Are two Topic objects, which are merged, equal? Are two > Topic objects, which are not yet merged, but should be merged, > equal?). > > Isn't that the purpose of equalsByID()? > > > Maybe, maybe not. The purpose of equalsByID() is "If I would take the > IDs of the two topic map items involved and compare them, would that > comparison yield true?". What does "equals by ID" mean in the case of TMDM topic maps in which objects may have multiple ids? Would the comparison require that the two topic map items had at least one item identifier in common? > Whether this definition happens to be equivalent or not to other > definitions of equality: I do not know, and this is out of the scope > of equalsByID(), and this is because I chose "equalsByID()" as name > and not "equals()". OK. I think it would be good to actually determine the existing semantics of equals() (in the existing providers), and if this is compatible with the requirements of equalsByID() (or can easily be made so), to use the name "equals" rather than "equalsByID". > > Or is there some difference in semantics between equals() and > > equalsByID()? > > > Depends on the intended semantics of equals() and, as they do not seem > to be defined currently (like equals() is not overriden), a difference > between equals() and equalsByID() is also not defined. > > ciao, > Xuân. > > P.S.: If you happen to be in Auckland in the next months, then just > drop me a note, then we can meet in person. :-) I don't get up there much, but you never know; I might well be. When are you planning to be in Auckland? -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: Lars H. <he...@se...> - 2008-03-11 09:45:54
|
Hi Xuân, [...] > Additionally, specific to TM4J, there is low to virtually no activity on > the project in the last 12 months (at least when I exclude commits by > myself), so even for major (API) changes, there is not really any reply > expected. Thus, it is quite unreasonable to ask and wait for no reply. Leaving the technical perspective aside, I disagree. Pushing TM4J forward is good, but you should have tried to explain what you want to do with TM4J. I think this is the way how Open Source works. Maybe the new "tmdm" package is the holy grail, but you should communicate with the other developers and the user base. How should others commit something if they do not have a plan? There is almost no documentation and you introduced dependencies to your libs (where is the source?). Ignoring the user base and potentially new TM4J-developers is the wrong way to achieve pretended progress. Best regards, Lars -- http://www.semagia.com |
From: Xuân B. <xua...@ba...> - 2008-03-11 09:37:43
|
Conal Tuohy wrote: > On Tue, 2008-03-11 at 16:39 +1300, Xuân Baldauf wrote: > > >> If I remember correctly, I think >> http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/TopicMapObjectImpl.java?revision=1.5&view=markup#l_126 is the reason for equalsByID(). This provider is a bridge between XML Topic Maps (in the style of TM4J 0.9.x) and TMDM (in the style of TM4J2). TMDM in general, and the TM4J2-implementation of TMDM in particular, does not require a TopicMapObject to have exactly one ID. Consequently, getID() is not defined, strictly speaking. If getID() is called anyways, some compatibility magic auto-creates an ID if no ID cannot be found or somehow inferred. However, this is a kludge (as a read-only method has a state-changing behaviour), and should be avoided, especially if the only purpose of calling getID() is comparing whether two TopicMapObjects are equal in some sense (which should be read-only-process in turn). You do not want to have an OutOfMemoryError just because you called getID(). >> > > Why not just use the equals() method then, Xuan? > Personally, I do not care about the name. However, care should be taken because we have multiple notions of equality in topic maps and in TM4J (like: Are two Topic objects, which are merged, equal? Are two Topic objects, which are not yet merged, but should be merged, equal?). > Isn't that the purpose of equalsByID()? > Maybe, maybe not. The purpose of equalsByID() is "If I would take the IDs of the two topic map items involved and compare them, would that comparison yield true?". Whether this definition happens to be equivalent or not to other definitions of equality: I do not know, and this is out of the scope of equalsByID(), and this is because I chose "equalsByID()" as name and not "equals()". > Or is there some difference in semantics between equals() and > equalsByID()? > Depends on the intended semantics of equals() and, as they do not seem to be defined currently (like equals() is not overriden), a difference between equals() and equalsByID() is also not defined. ciao, Xuân. P.S.: If you happen to be in Auckland in the next months, then just drop me a note, then we can meet in person. :-) |
From: Xuân B. <xua...@ba...> - 2008-03-11 08:58:37
|
Conal Tuohy wrote: > Hi Xuân > > I'm not convinced, actually. > > It seems to me you should have introduced a new, TMDM-flavoured > TopicMapObject interface, I did, see here: http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/TopicMapConstruct.java?revision=1.1&view=markup > rather than changing the old, XTM > 1.0-flavoured interface. > I did not change the old XTM 1.0-flavoured interface except for this one abstraction of equality. > As you yourself pointed out, the getID() method isn't appropriate for > TMDM-based topicmaps, so a distinct interface for TMDM TopicMapObjects > is probably better (rather than an extended one, with "deprecated" > bits). > There is, as org.tm4j.topicmap.tmdm.TopicMapConstruct.getItemIdentifiers() shows. > Personally, I think your effort to unify the XTM 1 and TMDM models is > too ambitious I don't unify into a greater model. > (although I don't know how you intend to achieve this > goal, because you haven't described your plan). It seems to me though > that you should instead have two distinct models, I do. > and to use a layering > approach to unify them. I do. http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/ is the translation layer. > The two models are IMHO not sufficiently > compatible to be simply "merged" I agree. > (as you have started to do). > I do not think so. > Mainly, though, I just think it's important to fully discuss these kinds > of disruptive changes before instituting them, or else they should be > done in a branch. The trunk is not the proper place for this kind of > speculative work. > The equalsByID() thing was done as fix to a specific problem, as far as I remember. It is not breaking any code using the API, and I was not aware that there was any code outside of TM4J actually implementing the API. Thus, it was reasonable to not expect any problems. Additionally, I considered (and still consider) this API "public, but extendable" (although I do not intend any further changes). But even though I do know now that there is external software implementing the API, I still think an approach like it is done with the Linux kernel is appropriate: 1. What is in the kernel gets refactored appropriately by those who do the refactoring. 2. What is outside but implements an inside interface has to be updated by the outside maintainers in order to mirror the kernel development. 3. Development freeze (=stopping changing APIs) over extended periods of time is unacceptable. 4. Who wants to be really conservative and not go the way of being up-to-date (both regarding breaking code and regarding reaping the fruits of the development) may stick with an old version. So, I consider a change in a project imposing a need of a change in an unknown external dependent project of 3 lines not necessarily disruptive. It is just normal that APIs evolve for certain needs (such as speed and reduction of side effects), and that external projects implementing these APIs need to implement new methods in these APIs if they want to mirror the development. Additionally, specific to TM4J, there is low to virtually no activity on the project in the last 12 months (at least when I exclude commits by myself), so even for major (API) changes, there is not really any reply expected. Thus, it is quite unreasonable to ask and wait for no reply. Thus, I think, if there is any progress to be expected at all, the burden of disagreeing (like writing e-mails and debating pros and cons) should be on those being otherwise passive (i.e. by default every change is allowed unless challenged, not by default every change is denied, unless allowed). I'd like to ask you to make your API implementation publicly writable (e.g. import it into the TM4J project under some open source licenses), then bad surprises like a need to adapt to new versions can be avoided. > Regards > > Con > > ciao, Xuân. |
From: Conal T. <con...@vu...> - 2008-03-11 04:16:02
|
On Tue, 2008-03-11 at 16:39 +1300, Xuân Baldauf wrote: > If I remember correctly, I think > http://tm4j.cvs.sourceforge.net/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/tm4j1/TopicMapObjectImpl.java?revision=1.5&view=markup#l_126 is the reason for equalsByID(). This provider is a bridge between XML Topic Maps (in the style of TM4J 0.9.x) and TMDM (in the style of TM4J2). TMDM in general, and the TM4J2-implementation of TMDM in particular, does not require a TopicMapObject to have exactly one ID. Consequently, getID() is not defined, strictly speaking. If getID() is called anyways, some compatibility magic auto-creates an ID if no ID cannot be found or somehow inferred. However, this is a kludge (as a read-only method has a state-changing behaviour), and should be avoided, especially if the only purpose of calling getID() is comparing whether two TopicMapObjects are equal in some sense (which should be read-only-process in turn). You do not want to have an OutOfMemoryError just because you called getID(). Why not just use the equals() method then, Xuan? Isn't that the purpose of equalsByID()? Or is there some difference in semantics between equals() and equalsByID()? -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: Conal T. <con...@vu...> - 2008-03-11 04:06:21
|
Hi Xuân I'm not convinced, actually. It seems to me you should have introduced a new, TMDM-flavoured TopicMapObject interface, rather than changing the old, XTM 1.0-flavoured interface. As you yourself pointed out, the getID() method isn't appropriate for TMDM-based topicmaps, so a distinct interface for TMDM TopicMapObjects is probably better (rather than an extended one, with "deprecated" bits). Personally, I think your effort to unify the XTM 1 and TMDM models is too ambitious (although I don't know how you intend to achieve this goal, because you haven't described your plan). It seems to me though that you should instead have two distinct models, and to use a layering approach to unify them. The two models are IMHO not sufficiently compatible to be simply "merged" (as you have started to do). Mainly, though, I just think it's important to fully discuss these kinds of disruptive changes before instituting them, or else they should be done in a branch. The trunk is not the proper place for this kind of speculative work. Regards Con -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: Conal T. <con...@vu...> - 2008-03-10 05:23:42
|
I have an old topicmap provider implementation which no longer links against recent builds of TM4j because of the addition of the equalsByID method to the TopicMapObject interface. It is certainly an easy method to implement, but I'm concerned because I don't even understand why the method has been added to TopicMapObject. It appears it may have been a "rough idea" that never really developed? In any case, it seems like a needless complication to me, and I am inclined to remove it. First I thought I would ask about it here. The point of the method appears to be to hide the data type of the object's id, presumably so that it could potentially be something other than a String. But this seems pointless to me, since actually these id properties are constrained to be strings (actually, XML names) by the XML Topic Maps specification. There's no way they could be anything other than strings! When I looked at each provider's implementation of the TopicMapObject interface in the TM4j source tree, they were all exactly the same: public boolean equalsByID(TopicMapObject o) { return getID().equals(o.getID()); } That fact in itself is a good indicator that the method doesn't properly belong in the TopicMapProvider interface. If there is no need for different providers to implement the method differently (and indeed the JavaDoc for the interface actually specifies the implementation!), then it belongs in a helper class, or as a protected helper method, but not as a public API. Each of the tm4j topic map providers had an implementation of TopicMapObject which included this method. These methods were used in at most a few places within that provider's package (e.g. org.tm4j.topicmap.hibernate.TopicImpl calls the method as a helper within isOfType(Topic)). In all of those cases the method could just as well have been protected - it didn't need to be part of the public API. Even if it were just a protected method of TopicMapObjectImpl (and not required by the TopicMapObject interface) it would seem hardly justifiable because it is just a single line of code, and used only a few times (not used at all in the unified provider!). Incidentally, I'm not sure if the implementation in the "unified" provider is correct - it's subtly inconsistent with equals(). The only use I could see of the method outside of provider classes was in org.tm4j.topicmap.utils.TopicMapWalker, where it was used just once, and could I think have just as well used equals() or at least getID().equals(o.getID()) So I propose to remove the equalsByID method from the interface, and replace its use in TopicMapWalker with equivalent code comparing id values. Any objections? Con -- Conal Tuohy New Zealand Electronic Text Centre www.nzetc.org |
From: juraj s. <jur...@go...> - 2008-02-05 15:19:19
|
Hi, I am using topic maps with Hibernate back-end and I have to merge two or more topic maps in database. Do I have to use TopicMapCopier like you mentioned in conversation from 2004-06-27 or is there now any other possibility to do that? If I have to use TopicMapCopier, can somebody please send me a piece of code, how to do it, when I have the topicMap objects. Thank you very much Best Regards Juraj |
From:
<xua...@ba...> - 2008-01-29 04:55:01
|
Kal Ahmed wrote: > > Hi Xu=C3=A2n > > =20 > > The reason I originally chose Apache 1.0 was that I wanted a license > with the minimum of restrictions on who could use the code. I > specifically did not want GPL in there as that forces a particular > software distribution model on the licensee (i.e. they have to make > their source available). > I understand that. :-) > > =20 > > IANAL but I would have thought that a project under GPL should be able > to use a library licensed under Apache as long as the library source > was available=E2=80=A6no ? > Unfortunately, for practical matters, no. At least http://www.fsf.org/licensing/licenses/ says: Apache License, Version 1.0 <http://www.apache.org/licenses/LICENSE-1= =2E0> This is a simple, permissive non-copyleft free software license with an advertising clause. This creates practical problems <http://www.gnu.org/philosophy/bsd.html> like those of the original BSD license, including incompatibility with the GNU GPL.= Actually, there are at least 2 types of "use". 1. The first type is "write your own software such that it references interfaces provided by the other software". This is almost always legal, even if the other software is not open source. 2. The second type is "distribute your own software along with the other software". This is only possible if at least one of the licenses for each of the component projects allows this. And the GPL does not allow this bundling for its GPL component unless the GPL, or a compatible license, applies to the other software. And this is where the compatibility issue comes into play. > Also, I=E2=80=99m not sure if the effect of having multiple licenses wo= uld be > to reduce FUD or increase it. > It is quite common nowadays to to be dual-licensed or multi-licensed in general. See http://en.wikipedia.org/wiki/Dual_license . One prominent example is the Firefox browser, which is multi-licensed under MPL v1.1, GPL v2, LGPL v2.1. Type "about:license" in your browser to see more about this. ;-) I think, if a user of TM4J actually wants to join TM4J with some other open source software, having an explicit statement "You can use TM4J under license X" (where X is also the license of the other open source software) actually creates the inverse of FUD, i.e. confidence that this is allowed, legal and intended, without the need to consult license compatibility matrices, which may not even exist for that particular combination of licenses. The effect for the user is that he|she can choose among the licenses. The more licenses, the more permissive. The effect for the developer is that he|she has to agree not only to one license, but to all licenses. That typically means that attribution and all the other requirements are retained as long as the project is not forked off and the forker decides to choose a subset of the possible licenses for his|her fork. > > The one other thing that is worth thinking about with a license is > attribution =E2=80=93 I think that if others are using our stuff the on= ly > thing I would like to see is an acknowledgement of that =E2=80=93 that = was one > of the things Apache 1.0 provided. > Maybe the requirement for attribution is one "restriction" on the user which makes Apache 1.0 incompatible with GPL v2. However, GPL v3 allows for an attribution restriction.=20 > > My preference would be for a single, permissive and unrestrictive > license that says something like =E2=80=9CTake this stuff, do what you = want > with it. If it=E2=80=99s good think about giving it back. If it=E2=80=99= s bad don=E2=80=99t > sue us. If you use it, please acknowledge our work.=E2=80=9D > Then, although it retains the FUD problem of not explicitly permitting to use another license, like multi-licensing would, maybe we should use a 3-clause BSD license (which is single, permissive, unrestrictive, and well known to be compatible with copyleft licenses) and add the statement, separately from the core license but next to it, "If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.", like it is done in the bzip2 license. For example, Firefox respects such requests and has following notices in "about:license": Optional Notices Some permissive software licenses request but do not require an acknowledgement of the use of their software. We are very grateful to the following people and projects for their contributions to this product: * The zlib <http://www.zlib.net/> compression library (Jean-loup Gailly, Mark Adler and team) * The bzip2 <http://www.bzip.org/> compression library (Julian Seward) * The libpng <http://www.libpng.org/pub/png/> graphics library (Glenn Randers-Pehrson and team) Note that this is even more permissive than using multi-licensing. Because in the multi-licensing case, using TM4J in closed source projects (i.e. when using TM4J under the original TM4J license) strongly requires attribution without exception; attribution is optional only when using TM4J under one of the other free software licenses. So if you want to require attribution in general while making it optional only if TM4J is distributed as free software under a copyleft-license (i.e. where it is unlikely that the TM4J heritage is obscured as availability of the combined source code is required when attribution is optional), multi-licensing is a good and known way to achieve this. > Cheers > > =20 > > Kal > ciao, Xu=C3=A2n. :-) > > =20 > > *From:* Xu=C3=A2n Baldauf > [mailto:xua...@ba...] > *Sent:* 26 January 2008 16:02 > *To:* Kal Ahmed; tm4...@li... > *Subject:* TM4J license broadening > > =20 > > Hi Kal, > > I'm thinking that it would be good if TM4J could be licensed under > additional licenses besides the Apache 1.0 license. One reason is that > the Apache 1.0 license is GPLv2-incompatible and GPLv3-incompatible, > limiting the linkability of TM4J with other open source software > projects. That's why I'd like to propose that TM4J should be licensed > under following licenses: > > * the original TM4J license (which is an Apache 1.0 license) > * the Apache 2 license > * the GPL v2 license > * the GPL v3 license > * the LGPL v2.1 license > * the MPL v1.1 license > > as well as any later versions of these licenses. > > The rationale behind this long list of licenses is that to ensure > linkability with other open source software projects once and forever. > The "as well as any later versions of these licenses" is an intended > loophole to allow for adaption to future legal developments in the > spirit of the current licenses which we do not yet know (i.e. a GPLv4, > an Apache 3 license, ...) by the respective license standard setting > committees. This makes the explicit listing of some of these licenses > unnecessary (because some of these licenses are compatible with > others), but I'd like the minimum-license-list to be as explicit as > possible such that any doubt cast on license compatibility does not > create fear, uncertainty or doubt regarding license applicability. > > > To achieve this license broadening, consent is needed from nearly > every author, you being the most prominent one, that's why I start > with you. (As time goes by, contacting authors becomes more difficult, > that's why I better start now than later.) > So, what do you (and others) think about this proposal? > > > ciao, > Xu=C3=A2n. > > (Message was resent due to tm4...@li... > <mailto:tm4...@li...> not accepting or at least > withholding posts from spam-thwarting e-mail-addresses.) > |
From:
<xua...@ba...> - 2008-01-26 16:04:29
|
Hi Kal, I'm thinking that it would be good if TM4J could be licensed under additional licenses besides the Apache 1.0 license. One reason is that the Apache 1.0 license is GPLv2-incompatible and GPLv3-incompatible, limiting the linkability of TM4J with other open source software projects. That's why I'd like to propose that TM4J should be licensed under following licenses: * the original TM4J license (which is an Apache 1.0 license) * the Apache 2 license * the GPL v2 license * the GPL v3 license * the LGPL v2.1 license * the MPL v1.1 license as well as any later versions of these licenses. The rationale behind this long list of licenses is that to ensure linkability with other open source software projects once and forever. The "as well as any later versions of these licenses" is an intended loophole to allow for adaption to future legal developments in the spirit of the current licenses which we do not yet know (i.e. a GPLv4, an Apache 3 license, ...) by the respective license standard setting committees. This makes the explicit listing of some of these licenses unnecessary (because some of these licenses are compatible with others), but I'd like the minimum-license-list to be as explicit as possible such that any doubt cast on license compatibility does not create fear, uncertainty or doubt regarding license applicability. To achieve this license broadening, consent is needed from nearly every author, you being the most prominent one, that's why I start with you. (As time goes by, contacting authors becomes more difficult, that's why I better start now than later.) So, what do you (and others) think about this proposal? ciao, Xu=E2n. (Message was resent due to tm4...@li... not accepting or at least withholding posts from spam-thwarting e-mail-addresses.) |
From: Dicheva, D. <dic...@ws...> - 2007-10-09 14:35:15
|
Hi, I've been trying from last night to send an announcement to top...@in... but kept receiving the message below. I've been canceling the postage and changing the subject of the email without success. Anybody has some idea what is going on? It is really frustrating ... I haven't had problems to send messages to this list before. Thanks, Darina -----Original Message----- From: top...@in... [mailto:top...@in...]=20 Sent: Tuesday, October 09, 2007 10:28 AM To: Dicheva, Darina Subject: Your message to topicmapmail awaits moderator approval Your mail to 'topicmapmail' with the subject TM4L Editor: new release Is being held until the list moderator can review it for approval. The reason it is being held: Message has a suspicious header Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: =20 http://www.infoloom.com/mailman/confirm/topicmapmail/c0cd66f6390649c69d8 49ddeb9dcf34b274350da |
From: Dicheva, D. <dic...@ws...> - 2007-10-09 13:55:25
|
Hi Stefan, > the download link is not working, please send a working one. Sorry about this (this is the danger of editing old emails :-) The correct link is http://compsci.wssu.edu/iis/nsdl/download.html > btw. if the editor is ontop of tmapi, you ship with it in package with my tinyTIM or xtm4xmldb or just tm4j? Currently it is shipped with tm4j only; we might look at tinyTIM - I am not sure what amount of effort would that require ... Any idea? > i plan to release a new version of tinytim this weekend with a new sql-backend. Great! All the very best, Darina thanx in advance Stefan Dicheva, Darina wrote: > Hello all, >=20 > I am pleased to announce that the TMAPI-based implementation of TM4L is > finally completed! Thanks to all of you who helped us and especially to > Lars H.! >=20 > Other new features added to TM4L include: > - topic map querying capabilities=20 > - visual topic map editing=20 > - conversion between topic maps and RDF data=20 > - plug-in architecture enabling users to add new features=20 > + more ... >=20 > The latest version of TM4L can be downloaded from=20 > http://www.wssu.edu/iis/NSDL/download.html > <http://www.wssu.edu/iis/NSDL/download.html=3D20>=20 >=20 > As always your feedback is welcome! >=20 > Cheers, > Darina > ---------- >=20 > Darina Dicheva > Winston-Salem State University > 3206 E.J. Jones Computer Science Bldg > Winston Salem, NC 27110 > Phone: 336-750-2484 > http://myweb.wssu.edu/dichevad/ > =20 >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Tm4j-users mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHC0VGL5hrdXRZQD8RAr8QAKCy/29SAhyiAizv3dqNvRpAwePe6ACgifgy 165XMfoaLE8MvbksAQtn03Q=3D =3DUxiG -----END PGP SIGNATURE----- |
From: Lars H. <he...@se...> - 2007-10-09 12:11:15
|
Hi Darina, > I am pleased to announce that the TMAPI-based implementation of TM4L is > finally completed! Congrats! :) [...] > The latest version of TM4L can be downloaded from > http://www.wssu.edu/iis/NSDL/download.html > <http://www.wssu.edu/iis/NSDL/download.html=20> The link is wrong, the correct one is <http://compsci.wssu.edu/iis/nsdl/download.html> Best regards, Lars -- http://www.semagia.com http://www.topicmaps.de/mailinglist/ German Topic Maps mailinglist |
From: Dicheva, D. <dic...@ws...> - 2007-10-09 00:16:35
|
Hello all, I am pleased to announce that the TMAPI-based implementation of TM4L is finally completed! Thanks to all of you who helped us and especially to Lars H.! Other new features added to TM4L include: - topic map querying capabilities=20 - visual topic map editing=20 - conversion between topic maps and RDF data=20 - plug-in architecture enabling users to add new features=20 + more ... The latest version of TM4L can be downloaded from=20 http://www.wssu.edu/iis/NSDL/download.html <http://www.wssu.edu/iis/NSDL/download.html=3D20>=20 As always your feedback is welcome! Cheers, Darina ---------- Darina Dicheva Winston-Salem State University 3206 E.J. Jones Computer Science Bldg Winston Salem, NC 27110 Phone: 336-750-2484 http://myweb.wssu.edu/dichevad/ =20 |
From: Dicheva, D. <dic...@ws...> - 2007-07-19 02:05:59
|
Hello all, I wonder how TOLOG can be used in a TMAPI-based app. We had it in TM4L before migrating to TMAPI... Any idea? Thanks, Darina |
From: Lars H. <he...@se...> - 2007-05-07 13:39:38
|
Hi Darina, Please start a new thread for new topics and don't use the old "tolog" thread (from June 2006!) to post new questions. Thank you in advance. :) I assume, you're using the RDBMS backend through TMAPI? I've to admit that I never tried such a combination. > I am trying to set a Hibernate backend for TM4L but don't understand the > concept of baseLocator for a topic map stored in a database. For > example, what should be given in the create statement below, if > "hibernate.connection.url" has a value of "jdbc:mysql://localhost/tm4l" > > createTopicMap(java.lang.String baseLocatorReference, java.lang.String > baseLocatorNotation) > Creates a new topic map with a specified base locator. You can use any locator you like. It has nothing to do with the database URI. The base locator is just the URI of the topic map (the 'storage address', if you like). If you say tm = tmSys.reateTopicMap("http://www.example.org/my-tm"); A new topic map with the base locator "http://www.example.org/my-tm" is created. I assume, that you have to provide the connection URI via TopicMapSystemFactory tmSysFac = TopicMapSystemFactory.newInstance(); tmSysFac.setProperty("property-name", "property-value") TopicMapSystem tmSys = tmSysFac.newTopicMapSystem(); TopicMap m = tmSys.createTopicMap(......) or TopicMap m = tmSys.getTopicMap("your-base-locator-here"); Best regards, Lars -- http://www.semagia.com http://www.topicmaps.de/mailinglist German Topic Maps mailinglist |