tm4j-users — Forum for users of the TM4J API or apps developed by this project.

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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

Re: [TM4J-users] TM4J Dev. Env. setup issues

[Suhas R. M. <suh...@or...>]

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

Re: [TM4J-users] TM4J Dev. Env. setup issues

[Kal A. <tec...@gm...>]

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
> >
> >
>
>

Re: [TM4J-users] TM4J Dev. Env. setup issues

[Suhas R. M. <suh...@or...>]

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
>
>

Re: [TM4J-users] TM4J Dev. Env. setup issues

[Kal A. <tec...@gm...>]

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
>
>

[TM4J-users] TM4J Dev. Env. setup issues

[Suhas R. M. <suh...@or...>]

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.

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Xuân B. <xua...@ba...>]

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
>   

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Xuân B. <xua...@ba...>]

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&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.

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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&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

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

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

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

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Xuân B. <xua...@ba...>]

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

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Xuân B. <xua...@ba...>]

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.

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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

Re: [TM4J-users] [Tm4j-developers] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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

[TM4J-users] TopicMapObject.equalsByID - is it really needed?

[Conal T. <con...@vu...>]

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

[TM4J-users] Topic Maps merging using Hibernate

[juraj s. <jur...@go...>]

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

Re: [TM4J-users] TM4J license broadening

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

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

[TM4J-users] TM4J license broadening

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

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

[TM4J-users] FW: Your message to topicmapmail awaits moderator approval

[Dicheva, D. <dic...@ws...>]

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

Re: [TM4J-users] TMAPI-based release of the TM4L Editor

[Dicheva, D. <dic...@ws...>]

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-----

Re: [TM4J-users] TMAPI-based release of the TM4L Editor

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

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

[TM4J-users] TMAPI-based release of the TM4L Editor

[Dicheva, D. <dic...@ws...>]

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

[TM4J-users] Using TOLOG from TMAPI ?

[Dicheva, D. <dic...@ws...>]

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

Re: [TM4J-users] Casting TMAPI - TM4J Topic Problem

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

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