Menu
▾
▴
tm4j-developers — Forum for issues related to development of TM4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(26) |
Jul
(22) |
Aug
(31) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(50) |
Feb
(51) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(21) |
Mar
(2) |
Apr
(29) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(40) |
Dec
(14) |
| 2004 |
Jan
(32) |
Feb
(30) |
Mar
(24) |
Apr
(13) |
May
(25) |
Jun
(14) |
Jul
(9) |
Aug
(21) |
Sep
(52) |
Oct
(9) |
Nov
(12) |
Dec
(6) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
(1) |
Apr
(38) |
May
(7) |
Jun
(7) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(3) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(13) |
Feb
(12) |
Mar
(53) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: assante <chr...@ha...> - 2002-06-07 09:55:32
|
Hi, this is my first posting to this list, so Hello to you all. Some months ago, I volunteered to start the developement of tmnav as a graphical user interface to tm4j. The last weeks I finished a small prototype. I've just checked the sources into the cvs as a new module, called tmnav. If you prefer to download a binary, you can do so at my site (http://www.folge2.de/work/tmnav/download.php). This link will remain valid, until we find a better location for the binary distribution. The prototype has no big functionality. You can open a map and browse through part of the structure. I publish it at this stage for two reasons: 1. Getting some attention for the project. 2. Getting feedback and collect ideas. There are a few fundamental open questions and maybe some of you have input on theese. - How to implement tmnav. As a standalone-application? An alternative may be an "eclipse plugin". Does someone has some deeper experience with eclipse? The advantage of eclipse would be to get a lot of prebuild infrastructure for free. Furthermore, integration of topicmaps into the developement process may be a real benefit for developers. - What visualisation toolkit to use. Currently I'm using touchgraph. Kal proposed to check out JGraph as well. Does anyone know alternatives? Clearly, there should be a swing based form for the most important element types (topics, associations...) - What JDK to use. I vote for 1.4 , but perhaps there are arguments against. Regards Christoph |
|
From: Smith, T. <Tim...@ds...> - 2002-06-07 07:02:08
|
Hi all, I think I am missing something, I used a Topic.getNames(), converted to get a group of BaseNames I then used baseNameArray[element].inScope(myScope) and did NOT get a true when myScope SHOULD (I think) have given one if the name is scoped by Topic B and TopicA is-a TopicB (class-instance) then if myScope is TopicA (remember name is scoped by TopicB) Shouldn't I get a positive? Sorry if this is overly confusing Tim Smith |
|
From: Florian G. H. <fg...@bk...> - 2002-06-06 22:11:12
|
Hello, I've now changed the rewritten Merge utility according to Kal's suggestio= n of=20 using the TopicMapProviderImpl class. However, one issue arises (try the=20 Merge utility with "http://www.topicmaps.org/xtm/1.0/core.xtm" for an=20 illustration): TopicMapProviderBase creates an InputSource from an InputStream. Let's sa= y=20 that the stream was obtained by invoking the getInputStream() method on a= =20 URLConnection because one was trying to read/add/merge a topic map identi= fied=20 by a URL (a common scenario, I guess). The InputSource has no way of know= ing=20 how to resolve URI's relative to the document that the InputStream=20 represents: for all it cares, it only deals with some InputStream, and=20 goodness knows where that stream might have come from. You would have to = use=20 InputSource.setSystemId() in order for the InputSource to resolve relativ= e=20 URIs correctly. So without that invocation of setSystemId(), the SAX pars= er=20 isn't even able to parse the document if the !DOCTYPE declaration does no= t=20 contain an absolute URI for the DTD (which is the case for core.xtm as=20 mentioned above). It gets worse. AKAIK there is no way to determine for sure whether the=20 InputStream was obtained from a URLConnection: if, in contrast, a stream = was=20 opened on a file, then fine, it's instanceof FileInputStream. Yet there i= s no=20 such thing as a URLConnectionInputStream; URLConnection.getInputStream()=20 returns just a generic java.io.InputStream. It is (again, to the best of = my=20 knowledge) impossible to determine what URL that InputStream was created=20 from, so even if TopicMapProviderBase did invoke InputSource.setSystemId(= ),=20 it would't know what system ID to use! Am I getting something wrong or are we looking at a, um, feature here? -- Florian --=20 Florian G. Haas <fg...@bk...> GnuPG public key: http://www.fgh.bkf.at/gpgkey.asc Key fingerprint: 3C24 E021 33B1 9E98 B94B 2F21 860A B693 1B33 BB3C |
|
From: Kal A. <ka...@te...> - 2002-06-04 19:48:25
|
But I am glad I did - this is a good start on rewriting the merge utility= =2E=20 There is one other thing which I would like to do (perhaps you can do it=20 Florian ?), which is to make the application load topic maps using the=20 TopicMapProvider.addTopicMap() method, rather than the old=20 XTMBuilder/XTMParser way. This is for two reasons: 1) I tell folks that the source for these apps are a good way to learn ho= w to=20 do basic things with TM4J (like reading and writing topic maps) 2) When we get support for alternate syntaxes (such as LTM) in TM4J, I wo= uld=20 like that support to be hidden behind addTopicMap() - so using that metho= d=20 would make the application "forward-compatible" with support for LTM. However, this is definitely a vast improvement. I have no problems with a= dding=20 jargs to the build tree as I have used it for other apps and I'm quite ha= ppy=20 with its quality and usefulness. Cheers, Kal On Wednesday 29 May 2002 18:16, Florian G. Haas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello! > > While in the process of putting together some functionality for > XHTML-from-XTM generation -- which will be checked in Real Soon Now --,= I > fiddled a bit with the Merge utility, which, as it happened, resulted i= n a > fairly complete re-write. :-) > > I used Steve Purcell's JArgs package > (http://sourceforge.net/projects/jargs) and added some new options. JAr= gs > is a largely GNU-compatible command line parser allowing for specifying > both short (-x) and long (--option) command line args, which makes it e= asy > to add new features without writing outrageously complicated parsing > routines. The rewritten Merge utility still writes either to stdout or = an > output file, but now additionally supports reading from stdin so you ca= n > pipe output from a TM generator or the like to it. This still lacks a l= ot > of documentation, but perhaps one or two of you can make the time for > taking a look at it. As usual, just a proposal -- no hard feelings if i= t's > rejected. Might be worthwhile to take a look at JArgs itself too: I'm a > bit ambivalent about it, it works fine but uses all sorts of odd > constructs such as nesting tons of inner classes and the like. > > When testing, apply the patch from the root of your TM4J CVS tree. > After recompiling, invoke Merge with the -? or --help switch to see wha= t > options it now supports. > > I'd be happy about comments. > Thanks in advance, > - -- Florian > > - -- > Florian G. Haas <fg...@bk...> > > GnuPG public key: http://www.fgh.bkf.at/gpgkey.asc > Key fingerprint: 3C24 E021 33B1 9E98 B94B 2F21 860A B693 1B33 BB3C > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE89RsJhgq2kxszuzwRAsTvAJ9Feh44cAvW8RhJ3C525l7PjK+5ewCgmBQz > PWxOu9o3Hj0FljkAGMcsr8Y=3D > =3DHShR > -----END PGP SIGNATURE----- --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Florian G. H. <fg...@bk...> - 2002-05-29 18:16:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! While in the process of putting together some functionality for XHTML-from-XTM generation -- which will be checked in Real Soon Now --, I fiddled a bit with the Merge utility, which, as it happened, resulted in a fairly complete re-write. :-) I used Steve Purcell's JArgs package (http://sourceforge.net/projects/jargs) and added some new options. JArgs is a largely GNU-compatible command line parser allowing for specifying both short (-x) and long (--option) command line args, which makes it easy to add new features without writing outrageously complicated parsing routines. The rewritten Merge utility still writes either to stdout or an output file, but now additionally supports reading from stdin so you can pipe output from a TM generator or the like to it. This still lacks a lot of documentation, but perhaps one or two of you can make the time for taking a look at it. As usual, just a proposal -- no hard feelings if it's rejected. Might be worthwhile to take a look at JArgs itself too: I'm a bit ambivalent about it, it works fine but uses all sorts of odd constructs such as nesting tons of inner classes and the like. When testing, apply the patch from the root of your TM4J CVS tree. After recompiling, invoke Merge with the -? or --help switch to see what options it now supports. I'd be happy about comments. Thanks in advance, - -- Florian - -- Florian G. Haas <fg...@bk...> GnuPG public key: http://www.fgh.bkf.at/gpgkey.asc Key fingerprint: 3C24 E021 33B1 9E98 B94B 2F21 860A B693 1B33 BB3C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE89RsJhgq2kxszuzwRAsTvAJ9Feh44cAvW8RhJ3C525l7PjK+5ewCgmBQz PWxOu9o3Hj0FljkAGMcsr8Y= =HShR -----END PGP SIGNATURE----- |
|
From: Kal A. <ka...@te...> - 2002-05-17 12:04:38
|
Hi all, This release contains a patch received from Sebastian Lutz which enables = the=20 TM4J parser to "round-trip" id attribute values from a parsed XTM file. T= here=20 are some restrictions on this, but when dealing with single XTM files=20 (without merging), this patch should always result in TopicMapObject.getI= D()=20 returning the value of the id attribute of the original XTM file element. Thanks to Sebastian for the patch! Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-05-07 12:58:59
|
Nope, its partially functional. I've implemented most of the Tolog=20 language[1]. The pieces currently not implemented are alternatives, the n= ot()=20 operator and the count() operator. This implementation also supports your= own=20 pluggable operators so you can take complex or non-standard operations an= d=20 implement them in Java and then use them from Tolog. Anybody who feels brave enough to have a play can look at the test progra= m for=20 some simple examples and at the Ontopia tutorial on Tolog [1]. Cheers, Kal [1] http://www.ontopia.net/omnigator/docs/query/tutorial.html On Tuesday 07 May 2002 08:50, Gerd Mueller wrote: > Hi Kal, > > I noticed that you've checked something in what looks like a Tolog > interpreter. Is it really a working Tolog-implementation or only the pa= rser > ? > > bye, > gerd > > _______________________________________________________________________= ____ >___ Gerd Mueller =20 > ge...@sm... SMB GmbH = =20 > http://www.smb-tec.com > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We sup= ply > the hardware. You get the recognition. Email Us: bandwidth@sourceforge.= net > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Gerd M. <ge...@sm...> - 2002-05-07 08:51:34
|
Hi Kal, I noticed that you've checked something in what looks like a Tolog interpreter. Is it really a working Tolog-implementation or only the parser ? bye, gerd ______________________________________________________________________________ Gerd Mueller ge...@sm... SMB GmbH http://www.smb-tec.com |
|
From: Kal A. <ka...@te...> - 2002-04-30 08:55:48
|
On Tuesday 30 April 2002 07:39, Gerd Mueller wrote: > On Mon, 29 Apr 2002 21:18:01 +0000 > > Kal Ahmed <ka...@te...> wrote: > > OK, I promise that this is the last email for this evening. > > > > Now that the dust has settled on JDK1.4, I would like to gather peopl= e's > > opinions on what JDK version the release after 0.7.0 (1.0 ? ;-) shoul= d > > require. My feeling is that we should move with the times and go up t= o > > JDK1.4. My reasons are: > > > > 1) TM4J has never supported development of applets that run in a brow= ser > > VM (i.e JDK 1.1.8). So there is nothing to be broken there. > > 2) JDK1.4 would enable us to ditch Log4J - reducing the number of > > additional jars we need to bundle up by one. > > Did you already work with the JDK1.4 logging stuff ? Is comparable to L= og4J > ? I really like Log4J, also because of the large number of add-ons > (EMail-logger, JDBC-logger, etc.). But finally I don't mind the JDK 1.4 > logging framework. I haven't worked with JDK1.4 logging really at all - most of my comments = are=20 based on reading the javadoc....probably not a good substitute for actual= ly=20 writing some code...then again, TM4J is where most of my Java code gets=20 written these days ;-) > > > However, there may be some arguments in favour of sticking with our > > current JDK level (1.3.1) - for example, I am kind of assuming that O= zone > > is happy with JDK1.4 (I can't think of any reason why not...I guess I > > should go try it > > > > :-). Finally, remember I am *not* talking about the 0.7.0 release wh= ich, > > > > when it happens, will still be JDK1.3.1 compatible. > > As far as I know nobody reported problems with JDK 1.4 and ozone, but > I didn't try it for myself. The only problem a had with JDK 1.4 was > the built-in XML support which conflicts sometimes with other > XML-parsers such as Xerces. > OK - it sounds like there shouldn't be a problem then. I have 1.4 install= ed on=20 my main development machine now - so I guess I can try it out today. Cheers, Kal |
|
From: Kal A. <ka...@te...> - 2002-04-30 08:50:55
|
On Monday 29 April 2002 20:36, Jack Park wrote: > I can only think of one reason for holding back: Macintosh. As far as = I > know, it's still locked into 1.3, but maybe that's changing > soon. Otherwise, 1.4 would, at least for me, be a good idea. > Thanks for the information, Jack! I hadn't realised that the Mac was stil= l on=20 1.3 - I'll see if I can find out anything about if/when 1.4 will be=20 available.=20 Cheers, Kal |
|
From: Gerd M. <Ger...@sm...> - 2002-04-30 07:48:54
|
> Hi all, > > I have finally managed to get the automatic conversion of our sitemap topic > map(s) into a website. You can see the results at http://tm4j.org/tm4j.html. > Many thanks to Florian Haas and Thomas Bauer for their work on the layout and > information design (not to mention much of the content!). > > There is still a lot of work to be done - getting more FAQs written up, > getting "news" topics integrated, integrating the javadoc topic map and more > tightly integrating the developer's documentation. Anyone inspired enough by > what we have so far to want to volunteer to help would be very welcome ;-) > > I would be interested to hear your comments on the site both in terms of > layout and content. My feeling is that once we have a "news" topic map > integrated we are ready to go live with it and can then carry on expanding it > as and when we like. Really great work ! The only thing I was slightly confused about at first is the small shortcut frame. It was not quite clear to me what this is about. Also I've got an idea for a nice feature: If you click the topic types (that one within brackets, e.g. part or responsable entity) it would be nice to get a list of all topics which have this type, e.g. all parts. bye, gerd ________________________________________________________________ Gerd Mueller ge...@sm... SMB GmbH http://www.smb-tec.com |
|
From: Gerd M. <Ger...@sm...> - 2002-04-30 07:41:07
|
On Mon, 29 Apr 2002 21:18:01 +0000 Kal Ahmed <ka...@te...> wrote: > OK, I promise that this is the last email for this evening. > > Now that the dust has settled on JDK1.4, I would like to gather people's > opinions on what JDK version the release after 0.7.0 (1.0 ? ;-) should > require. My feeling is that we should move with the times and go up to > JDK1.4. My reasons are: > > 1) TM4J has never supported development of applets that run in a browser VM > (i.e JDK 1.1.8). So there is nothing to be broken there. > 2) JDK1.4 would enable us to ditch Log4J - reducing the number of additional > jars we need to bundle up by one. Did you already work with the JDK1.4 logging stuff ? Is comparable to Log4J ? I really like Log4J, also because of the large number of add-ons (EMail-logger, JDBC-logger, etc.). But finally I don't mind the JDK 1.4 logging framework. > However, there may be some arguments in favour of sticking with our current > JDK level (1.3.1) - for example, I am kind of assuming that Ozone is happy > with JDK1.4 (I can't think of any reason why not...I guess I should go try it > :-). Finally, remember I am *not* talking about the 0.7.0 release which, > when it happens, will still be JDK1.3.1 compatible. As far as I know nobody reported problems with JDK 1.4 and ozone, but I didn't try it for myself. The only problem a had with JDK 1.4 was the built-in XML support which conflicts sometimes with other XML-parsers such as Xerces. Best Regards, Gerd ________________________________________________________________ Gerd Mueller ge...@sm... SMB GmbH http://www.smb-tec.com |
|
From: Jack P. <jac...@th...> - 2002-04-29 20:39:24
|
I can only think of one reason for holding back: Macintosh. As far as I know, it's still locked into 1.3, but maybe that's changing soon. Otherwise, 1.4 would, at least for me, be a good idea. Cheers Jack At 09:18 PM 4/29/2002 +0000, Kal Ahmed wrote: >OK, I promise that this is the last email for this evening. > >Now that the dust has settled on JDK1.4, I would like to gather people's >opinions on what JDK version the release after 0.7.0 (1.0 ? ;-) should >require. My feeling is that we should move with the times and go up to >JDK1.4. My reasons are: > >1) TM4J has never supported development of applets that run in a browser VM >(i.e JDK 1.1.8). So there is nothing to be broken there. >2) JDK1.4 would enable us to ditch Log4J - reducing the number of additional >jars we need to bundle up by one. >3) Most importantly, JDK1.4 has much better URI handling than JDK1.3.x - my >impression is that with JDK1.4 we could remove the org.tm4j.net package >entirely. JDK1.4 URIs are serialisable, so there should be no probs with the >Ozone implementation. Moving to JDK1.4 would also mean that developers would >be able to use a familiar URI object interface rather than having to learn >the TM4J way. To be honest, I never really saw all the network address >handling as being a fundamental part of TM4J - I just did it because I had >to...and now I'm quite glad that Sun have thrown me a lifeline to get out of >having to maintain it (and implement URNs ;-) > >However, there may be some arguments in favour of sticking with our current >JDK level (1.3.1) - for example, I am kind of assuming that Ozone is happy >with JDK1.4 (I can't think of any reason why not...I guess I should go try it >:-). Finally, remember I am *not* talking about the 0.7.0 release which, >when it happens, will still be JDK1.3.1 compatible. > >If you have any comments on this, please share them! > >Cheers, > >Kal >-- >Kal Ahmed, tecqhuila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com > > >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Kal A. <ka...@te...> - 2002-04-29 20:19:37
|
OK, I promise that this is the last email for this evening. Now that the dust has settled on JDK1.4, I would like to gather people's=20 opinions on what JDK version the release after 0.7.0 (1.0 ? ;-) should=20 require. My feeling is that we should move with the times and go up to=20 JDK1.4. My reasons are: 1) TM4J has never supported development of applets that run in a browser = VM=20 (i.e JDK 1.1.8). So there is nothing to be broken there. 2) JDK1.4 would enable us to ditch Log4J - reducing the number of additio= nal=20 jars we need to bundle up by one. 3) Most importantly, JDK1.4 has much better URI handling than JDK1.3.x - = my=20 impression is that with JDK1.4 we could remove the org.tm4j.net package=20 entirely. JDK1.4 URIs are serialisable, so there should be no probs with = the=20 Ozone implementation. Moving to JDK1.4 would also mean that developers wo= uld=20 be able to use a familiar URI object interface rather than having to lear= n=20 the TM4J way. To be honest, I never really saw all the network address=20 handling as being a fundamental part of TM4J - I just did it because I ha= d=20 to...and now I'm quite glad that Sun have thrown me a lifeline to get out= of=20 having to maintain it (and implement URNs ;-) However, there may be some arguments in favour of sticking with our curre= nt=20 JDK level (1.3.1) - for example, I am kind of assuming that Ozone is happ= y=20 with JDK1.4 (I can't think of any reason why not...I guess I should go tr= y it=20 :-). Finally, remember I am *not* talking about the 0.7.0 release which,= =20 when it happens, will still be JDK1.3.1 compatible. If you have any comments on this, please share them! Cheers, Kal --=20 Kal Ahmed, tecqhuila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-04-29 20:07:50
|
Hi again! One of the outstanding tasks for 0.7.0 is to implement URN support. I am = now=20 in doubt as to whether to do this completely. Here are my reasons: 1) I don't know of many people making use of URNs rather than URLs for su= bject=20 addressing. 2) The current URILocator interface *kind of* supports URNs - after all a= URN=20 will parse as a URI, it is just that resolveRelative is meaningless for U= RNs=20 (and probably won't work correctly with the current URILocator implementa= tion=20 - though I haven't checked). It is possible for TM4J currently to read a=20 topic map containing URIs and to perform the usual merging operations bas= ed=20 on those and to export them again. The real problems is in the API which = is=20 not flexible enough to handle a non-hierarchical URI 3) With the advent of the URI class in JDK1.4, the whole org.tm4j.net pac= kage=20 needs to be re-examined. I'm sure that some of you will argue with (1), but I am also equally sure= that=20 the provisions in TM4J as it stands (as detailed in (2) ) are probably=20 sufficient. I would definitely like to hear from you if they are not. As for (3) - there is a wider discussion to be had about TM4J 1.0 (yes, I= am=20 thinking that after 0.7 we should finally make the big push to 1.0 :-) an= d=20 JDK 1.4. That is probably big enough to be in a separate thread... Cheers, Kal --=20 Kal Ahmed, tecqhuila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-04-29 20:01:15
|
Hi all, I'm in the process of working out how we can rationalise the logging in T= M4J.=20 First of all I propose that for 0.7.0 we continue to use Log4J - despite=20 JDK1.4 now having its own logging mechanism. Secondly I would like to make sure that all logging is generated using th= e=20 org.tm4j prefix for the logging category. Thirdly, I would like to move away from the use of class names for logs t= o=20 using specific log names for specific *areas* of functionality. This may = mean=20 that certain classes will end up writing to multiple logs (though I doubt= =20 that this will be very common in our code base). Here is my proposal for the initial set of logging categories. Please hav= e a=20 look over this and let me know if there are any cateories missing or uncl= ear. org.tm4j.topicmap=09- Log all messages to do with basic topic=20 =09=09=09 map processing. Also use to log less verbose =09=09=09 messages from the backend (e.g "Cannot open =09=09=09 database") org.tm4j.topicmap.index - Indexing related messages org.tm4j.topicmap.parser - Topic map parsing and building messages org.tm4j.topicmap.backend.ozone - Ozone specific messages org.tm4j.topicmap.backend.dom - DOM backend messages org.tm4j.topicmap.events - Logging of event processing / handling org.tm4j.topicmap.tolog - Logging of query processing org.tm4j.net - Logging of locator parsing/resolution messages Cheers, Kal --=20 Kal Ahmed, tecqhuila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-04-29 16:33:39
|
Hi all, I have finally managed to get the automatic conversion of our sitemap top= ic=20 map(s) into a website. You can see the results at http://tm4j.org/tm4j.ht= ml.=20 Many thanks to Florian Haas and Thomas Bauer for their work on the layout= and=20 information design (not to mention much of the content!). There is still a lot of work to be done - getting more FAQs written up,=20 getting "news" topics integrated, integrating the javadoc topic map and m= ore=20 tightly integrating the developer's documentation. Anyone inspired enough= by=20 what we have so far to want to volunteer to help would be very welcome ;-= ) I would be interested to hear your comments on the site both in terms of=20 layout and content. My feeling is that once we have a "news" topic map=20 integrated we are ready to go live with it and can then carry on expandin= g it=20 as and when we like. Technical details: Because SourceForge does not support a servlet container on their hosted = site,=20 the pages are all statically generated and uploaded in a single batch. Th= e=20 actual mechanism for creating the website is basically Velocity with some= =20 extensions to make it easier to work with topic maps. The source topic ma= ps=20 themselves can be found in CVSROOT/tm4j/resource/topicmaps/sitemap. End technical details. Cheers, Kal --=20 Kal Ahmed, tecqhuila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-04-01 11:43:08
|
Thanks for the patch Jeff ! Its now checked it in.... Cheers, Kal At 23:20 28/03/2002 +1100, Jeff Turner wrote: >Thanks, it's looking a lot healthier. Attached is a small patch that >fixes one last exception. > > >--Jeff > >On Wed, Mar 27, 2002 at 11:43:21AM +0000, Kal Ahmed wrote: > > Oops! My bad - I added that package recently and obviously didn't add > it to > > CVS. I'll check it in ASAP. > > > > Cheers, > > > > Kal |
|
From: Jeff T. <je...@so...> - 2002-03-28 12:13:53
|
Thanks, it's looking a lot healthier. Attached is a small patch that fixes one last exception. --Jeff On Wed, Mar 27, 2002 at 11:43:21AM +0000, Kal Ahmed wrote: > Oops! My bad - I added that package recently and obviously didn't add it to > CVS. I'll check it in ASAP. > > Cheers, > > Kal |
|
From: Kal A. <ka...@te...> - 2002-03-27 11:45:08
|
Oops! My bad - I added that package recently and obviously didn't add it to CVS. I'll check it in ASAP. Cheers, Kal At 22:00 27/03/2002 +1100, Jeff Turner wrote: >Hi, > >I've just checked tm4j out of CVS, and am trying to build. Apparently >all the jars are included, so I just have to run Ant. When Ant gets to >the 'ozone-base' target, it dies with a bunch of errors: > >ozone-base: > [javac] Compiling 38 source files to /home/jeff/java/tm4j/build/classes > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:99 > : package org.tm4j.topicmap.ozone.index does not exist > [javac] import org.tm4j.topicmap.ozone.index.*; > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapObjectImpl.java:366: > unindexObject(org.tm4j.topicmap.TopicMapObject) has private access in > org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] ((OzoneTopicMapImpl)m_topicmap).unindexObject(this); > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1399: > cannot resolve symbol > [javac] symbol : class OzoneIndexManagerImpl > [javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] OzoneIndexManagerImpl.class.getName(), > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1401: > cannot resolve symbol > [javac] symbol : class OzoneIndexManager > [javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] > ((OzoneIndexManager)m_indexManager).initialise(this); > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1402: > cannot resolve symbol > [javac] symbol : class OzoneIndexProvider > [javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] OzoneIndexProvider basicIndexProvider = > (OzoneIndexProvider)database().createObject( > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1402: > cannot resolve symbol > [javac] symbol : class OzoneIndexProvider > [javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] OzoneIndexProvider basicIndexProvider = > (OzoneIndexProvider)database().createObject( > [javac] ^ > [javac] > /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1403: > cannot resolve symbol > [javac] symbol : class OzoneBasicIndexProvider > [javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl > [javac] OzoneBasicIndexProvider.class.getName(), > [javac] ^ > > >Am I doing anything wrong here? I'm using Ant 1.4.1 with a clean classpath. >Perhaps the directory src/org/tm4j/topicmap/ozone/index/ wasn't checked in? > > >thanks, > >--Jeff > >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Jeff T. <je...@so...> - 2002-03-27 10:53:25
|
Hi,
I've just checked tm4j out of CVS, and am trying to build. Apparently
all the jars are included, so I just have to run Ant. When Ant gets to
the 'ozone-base' target, it dies with a bunch of errors:
ozone-base:
[javac] Compiling 38 source files to /home/jeff/java/tm4j/build/classes
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:99: package org.tm4j.topicmap.ozone.index does not exist
[javac] import org.tm4j.topicmap.ozone.index.*;
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapObjectImpl.java:366: unindexObject(org.tm4j.topicmap.TopicMapObject) has private access in org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] ((OzoneTopicMapImpl)m_topicmap).unindexObject(this);
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1399: cannot resolve symbol
[javac] symbol : class OzoneIndexManagerImpl
[javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] OzoneIndexManagerImpl.class.getName(),
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1401: cannot resolve symbol
[javac] symbol : class OzoneIndexManager
[javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] ((OzoneIndexManager)m_indexManager).initialise(this);
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1402: cannot resolve symbol
[javac] symbol : class OzoneIndexProvider
[javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] OzoneIndexProvider basicIndexProvider = (OzoneIndexProvider)database().createObject(
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1402: cannot resolve symbol
[javac] symbol : class OzoneIndexProvider
[javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] OzoneIndexProvider basicIndexProvider = (OzoneIndexProvider)database().createObject(
[javac] ^
[javac] /home/jeff/java/tm4j/src/org/tm4j/topicmap/ozone/OzoneTopicMapImpl.java:1403: cannot resolve symbol
[javac] symbol : class OzoneBasicIndexProvider
[javac] location: class org.tm4j.topicmap.ozone.OzoneTopicMapImpl
[javac] OzoneBasicIndexProvider.class.getName(),
[javac] ^
Am I doing anything wrong here? I'm using Ant 1.4.1 with a clean classpath.
Perhaps the directory src/org/tm4j/topicmap/ozone/index/ wasn't checked in?
thanks,
--Jeff
|
|
From: Jack P. <jac...@th...> - 2002-03-14 15:22:29
|
I've begun to make comments along this line at http://graphs.memes.net Do you folks think that's an appropriate place to evolve a discussion on using, say, GXL as a base API on which database servers can plug into the backside and various wrappers can plug into the front side? Cheers Jack At 05:33 PM 2/28/2002 +0000, Murray Altheim wrote: >Kal Ahmed wrote: >[...] >>>I have a preliminary XTM-to-TouchGraph converter working, though it is >>>missing a good deal of the topic map (such as occurrences and any sort >>>of interactive features). As a display tool for topics, associations, >>>and *some* of the scopes it works passably. But for now I won't be >>>spending so much time on it as my Ph.D duties are calling louder. But >>>perhaps working together on a Java API for XTM-in-TG I'd be happy to >>>lend a hand >>That sounds cool. I think that there are two independent things which we >>could collaborate on here - one is a common visualisation for XTM in TG >>(e.g. what should be displayed as TG nodes and what should be TG arcs, >>conventions on the use of colour, shapes and labels) such that two >>different apps displaying XTM in TG could do so in a consistent manner. >>The second would be a generic topic map viewer using TG (possibly built >>on top of TMAPI). The third thing might be if I can just pick your brains >>if I get stuck on the TG coding... ;-) > >Gad, I hope you don't have to pick my brains. I was thinking it'd be >the other way around. Sometime this spring I hope to be able to release >my Ceryle application, which should provide a framework upon which some >of this can be built. It has a working implementation of Xindice plus >XNode (the API I wrote for putting metadata-laden XML into Xindice that >will hopefully make it into the Apache submission), plus a working >of TG that will (hopefully) have some sort of import and export to and >from GXL and XTM, though currently I'm not at all happy with it. > >[...] >>>I instead decided to look at how GXL could be used for this purpose, >>>and that's when the light bulb went off -- it was an obvious choice for >>>a common syntax. I've also written a TG-to-GXL converter in the process, >>>then realized I wanted a more generalized approach. >> >>An XML graph vocabulary is the obvious lowest-common-denominator >>representation for TMs, CGs, RDF et al. I haven't (yet) looked deeply >>into GXL - I have skimmed over some of the pages from Jacks's reference. >>My feeling is that GXL as a vocabulary is interesting though as you point >>out somewhat limiting for use by humans because of its verbosity. In >>using it as a lingua-franca for different represntational forms, you will >>undoubtedly run into semantic problems. However, having said all that, >>the nice simple graph model that GXL encodes would be an interesting >>basis for a "node engine" that handles multiple higher-level >>representations of which TM4J could be one. > >I don't think GXL will be any more limiting than RDF, in fact I like it >a lot better than RDF as a syntax because it doesn't mix the lexical >with the grammar, no XML namespaces, etc. I think Jack, you and I are >thinking pretty alike on this. I'm just watching as the GXL researchers >develop a suitable schema language -- there's been a post recently in >this regard on their mailing list, but I've not had time to investigate >further. > >Cheers, > >Murray > > |
|
From: Kal A. <ka...@te...> - 2002-03-03 10:25:57
|
Hi all, This is just a heads up for anyone working in the R_0_6_1 branch of the tree. I plan to do a build and release 0.6.1 tomorrow - Monday 4th March. If you have anything that is not checked into the tree by that time it will miss the release. If you have some important changes not checked in, please let me know so we can decide whether to postpone the release. Note, this does not affect development in the main trunk of the source code - only in the R_0_6_1 branch Cheers, Kal |
|
From: Kal A. <ka...@te...> - 2002-03-01 09:31:21
|
Looks like we are getting close here. Another batch of changes just checked in. Comments are still welcome! Cheers, Kal |
|
From: Kal A. <ka...@te...> - 2002-02-28 20:43:39
|
At 21:02 28/02/2002 +0100, Florian G. Haas wrote: >Kal, > >here are a few comments. > >1. The fact that the methods returning an IndexMeta object are called >getIndexMeta() in IndexProvider and getIndexMetaData() in IndexManager seems >like an inconsistency to me. Agree - will rename to getIndexMeta() as this matches the class name. >2. Perhaps IndexManager.hasIndex(String) should be renamed to >isRegistered(String) or isRegisteredIndex(String). In addition, I think that >since already have IndexMeta.isAutomaticallyUpdated(), we should also have >an isAutomaticallyOpened() replacing requiresOpen() (with return values >reversed, of course). Good suggestions! >3. I think that IndexProvider.getIndexNames() should be renamed to >getIndexClassNames(), or perhaps be amended/replaced by a getIndexClasses() >method returning a Class[] array. A boolean isSupportedIndex(Class >indexClass) method may also be helpful. Or one might go the whole nine yards >and overload close(), getIndex(), getIndexMeta() and open() in such a way >that they also accept an argument of type Class, representing the index >class. The same could be done to the methods in IndexManager. I wanted to keep the IndexProvider interface as small and easy to implement as possible - it really only needs to expose methods for the IndexManager implementations to use. So I'll keep these suggestions in my back pocket for now...but I do think that overloading the IndexManager functions to accept Class parameters as well as String parameters makes sense. >4. Index.reindex() documents that it throws UnsupportedOperationException >which does not exist. it is java.lang.UnsupportedOperationException. >5. IndexProvider.getIndex() and IndexProvider.close() both document two >exceptions which they do not throw. Oops - my mistake - too eager to get the updates out :) They should both have a throws clause. >6. IndexManager.getIndex() documents one exception which it does not throw. Another "itchy commit finger" error ;-) >Hope I'm making sense, Definitely! Thanks for taking the time to review and comment. Cheers, Kal |
153 messages has been excluded from this view by a project administrator.
