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: SourceForge.net <no...@so...> - 2004-02-17 17:27:56
|
Feature Requests item #705170, was opened at 2003-03-17 20:14 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=705170&group_id=27895 Category: None Group: Next Release (example) Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) >Assigned to: Kal Ahmed (kal_ahmed) Summary: Document required libs Initial Comment: Document which JAR files from the lib directory are needed to use which of the different back-end implementations. The idea being to allow developers to remove the JAR files which are not required by the back-end(s) they are not planning to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=705170&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-02-17 17:27:41
|
Feature Requests item #581622, was opened at 2002-07-15 11:39 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=581622&group_id=27895 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Harald Kuhn (harald_kuhn) Summary: Text indexing Initial Comment: Create a simple text index implementation using Lucene. Should plug in as another standard index interface. ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-02-17 17:22 Message: Logged In: YES user_id=176992 Initial implementation checked into CVS. Will be part of 0.9.0 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=581622&group_id=27895 |
|
From: Kal A. <ka...@te...> - 2004-02-02 21:26:12
|
On Mon, 2004-02-02 at 21:02, Stefan Lischke wrote: > Hi there, > > I get the Feature Request eMail from Kal, in which he proposed to allow > XML Data in the resourceData Element. > As far as i know this will also be allowed in the next XTM standard. > > I have some discussion points for you: > XTM is metadata for some real data, maybe in an occurrence or directly > in resourceData. So it is not enough for a TopicMap engine to just > handle/index/query the Metadata. I think it should also be possible to > query the "real Data" inside the resourceData Element. > Since we are working with XML and we allow XML-Tags in resourceData, > than querys can be done via XPath or XQuery. > You all are pinned to the relational or OO Backend for a TopicMap > Engine, so querying by XPath or doing XQuery on Gigabytes of TopicMaps > should be very difficult to implement. > That is true, but the topic maps model is not the same as the XTM syntax - when you have to consider merging and the topic references (which create a graph), then it gets quite a lot more difficult - especially when you can have cases where the merging of two topics could then cause further merging because they change how names are scoped. > I want to open discussion about a native XML Backend for a TopicMap > engine, like i did with XTM4XMLDB (also @sf.net). I know my > implementation of TMAPI with a native XML:DB Backend is really a quick > hack, but i think it is worth to think about. > Currently with eXist (also @sf.net) as Backend, i don't have to create > indexes for all the TopicMapFields like basename and so on, cause the > XMLDB is indexing the whole DOM. If you want something quick out of > Gigabytes of TopicMaps XPath is doing the work in milliseconds. You can > query for something inside xtm namespace or just inside the resourceData > without any problems. > There was a DOM backend that was started a while ago but it didn't get completed. I had always thought that this DOM backend could possibly be a good way to use a native XML database. My thought was that you could annotate the XTM syntax with additional attributes (maybe in a different namespace) to handle the results of merging and make it easier to then query the XML structure with XPath to do TM4J API calls. There is another alternative, which would be to use TM4J's JDBC/Ozone implementation in paralell with an XML DB implementation, with the XML DB implementation providing an Index view. This would be a parallel to the FullTextIndex that Harald has just committed to CVS. So it would only handle queries against the content of resourceData elements for example. That way you could represent the topic map as data in JDBC/Ozone backend + a number of micro-documents in a native XML database. Just a thought :) Cheers, Kal -- Kal Ahmed <ka...@te...> techquila |
|
From: Stefan L. <li...@no...> - 2004-02-02 21:03:47
|
Hi there, I get the Feature Request eMail from Kal, in which he proposed to allow XML Data in the resourceData Element. As far as i know this will also be allowed in the next XTM standard. I have some discussion points for you: XTM is metadata for some real data, maybe in an occurrence or directly in resourceData. So it is not enough for a TopicMap engine to just handle/index/query the Metadata. I think it should also be possible to query the "real Data" inside the resourceData Element. Since we are working with XML and we allow XML-Tags in resourceData, than querys can be done via XPath or XQuery. You all are pinned to the relational or OO Backend for a TopicMap Engine, so querying by XPath or doing XQuery on Gigabytes of TopicMaps should be very difficult to implement. I want to open discussion about a native XML Backend for a TopicMap engine, like i did with XTM4XMLDB (also @sf.net). I know my implementation of TMAPI with a native XML:DB Backend is really a quick hack, but i think it is worth to think about. Currently with eXist (also @sf.net) as Backend, i don't have to create indexes for all the TopicMapFields like basename and so on, cause the XMLDB is indexing the whole DOM. If you want something quick out of Gigabytes of TopicMaps XPath is doing the work in milliseconds. You can query for something inside xtm namespace or just inside the resourceData without any problems. I hope i can start a friendly discussion, and i hope murray will not be angry with me cause i said something about putting xml-tags inside resourceData :-) Stefan |
|
From: <vir...@bo...> - 2004-02-01 05:26:52
|
************* eManager Notification ************** Attached files with executable extension have been deleted. (i.e. *.exe). Ausführbare Attachments wurden gelöscht (z.B. *.exe) Source mailbox: "tm4...@li..." Destination mailbox(es): jo...@bo... Policy: Replaced with text Attachment file name: readme.cmd - application/octet-stream Action: Attachment Removal ******************* End of message ******************* |
|
From: SourceForge.net <no...@so...> - 2004-01-31 18:07:08
|
Feature Requests item #502434, was opened at 2002-01-11 19:00 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 Category: Programmer Utils Group: Next Release (example) >Status: Closed Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Kal Ahmed (kal_ahmed) Summary: Scope Filter Initial Comment: A WalkerFilter to pass or skip associations, base names or occurrences which match a specified scope. ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-31 18:07 Message: Logged In: YES user_id=176992 Implemented org.tm4j.topicmap.utils.ScopeWalkerFilter for general scoped object processing and org.tm4j.topicmap.utils.InScopeWalkerFilter as a filter to only pass through in-scope object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:11:49
|
Bugs item #852074, was opened at 2003-12-01 13:54 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=852074&group_id=27895 >Category: TM4Web Group: TM4Web/Velocity 0.1 Status: Open Resolution: None Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Kal Ahmed (kal_ahmed) Summary: Factory does not find correct constructor Initial Comment: The Factory class locates the wrong constructor when invoked on a class with multiple constructors with different numbers of parameters. In this case, the org.tm4j.vtl.comparators.ResultsComparator class has constructors: ResultsComparator(UnaryFunction) and ResultsComparator(UnaryFunction, Comparator) Using the factory for Velocity as: $factory.create("org.tm4j.vtl.comparators.ResultsComparator", $extractor) Results in an error message saying that the constructor was invoked with the wrong number of arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=852074&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:11:34
|
Bugs item #881422, was opened at 2004-01-21 14:56 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 >Category: TM4Web Group: TM4Web/Velocity 0.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Kal Ahmed (kal_ahmed) Summary: TM4Web: display of special chars broken in main display Initial Comment: hi, i am very impressed by the recent status of TMNav and TM4Web. thank you! here is a minor problem: TM4Web's display method for all topics on the main page seems broken (display works in topic.vm) in addition, TMNav displays topics only fine when (4) is used (äöü...). this behaviour does not seem to depend on using LTM char encoding headers (none = default, @"utf-8" or @"ISO-8859-1"). used versions: - tmnav-0.2.7a1-bin (alpha) - tm4web-velocity-bin-0.1-nodeps.zip my example topic: [Umlaute = "Umlaute_ä_œ_ Œ_Œ_œ_äöüß_ÄÖÜ"] i.e.: (1) ä (2) œ_ Œ (oe/OE lig) (3) Œ_œ (same) (4) äöüß_ÄÖÜ results: -------- TMNav: (4) ok TM4Web: Main page with all topics: none working (4) looks like UTF-8 viewed in ISO-8859-1 topic.vm: (1), (2), (3) ok alex -- Alexander Sigel, M.A. U Cologne, Dept. for Information Systems & Information Management si...@wi... http://wim.uni-koeln.de/ phone +49 221 470-5322 Pohligstr. 1, Room 406, 50969 Köln, GERMANY --- ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-26 16:15 Message: Logged In: YES user_id=176992 All pages generated by TM4Web/Velocity should be UTF-8 encoded. I think this might be a Tomcat problem that you are seeing. You don't say which servlet container you are using, but Tomcat 4.1.29 does not set the HTTP headers specifying content encoding properly. I have found that everything is fine with Tomcat 4.1.27. Can you check this out and let me know if the problem is still there with the older version of Tomcat ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:07:42
|
Feature Requests item #707672, was opened at 2003-03-21 18:42 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 Category: Programmer Utils >Group: Next Release (example) Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Kal Ahmed (kal_ahmed) Summary: Canonical XTM export Initial Comment: Utility to export XTM files in canonical form as defined by Ontopia at http://www.ontopia.net/topicmaps/materials/cxtm.html ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-31 00:01 Message: Logged In: YES user_id=176992 Hmmm....now there's an idea! :-) ---------------------------------------------------------------------- Comment By: Lars Marius Garshol (larsga) Date: 2004-01-22 18:53 Message: Logged In: YES user_id=39120 It might be better to add support for the brand new canonical format defined in: ISO 13250-4: Topic Maps -- Canonicalization. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:07:24
|
Feature Requests item #704521, was opened at 2003-03-16 15:22 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=704521&group_id=27895 >Category: Performance Enhancement >Group: Next Release (example) Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Nobody/Anonymous (nobody) Summary: Improve Hibernate Import Performance Initial Comment: Look into methods to improve performance of the Hibernate back-end. Especially in import. Need to find out why import of 1.6MB XTM file takes up to an hour to process against a MySQL database. Could be related to connection pooling or to the fine-grained transactions used by the back-end. This may mean that it is necessary to allow coarser-grained transactions to be controlled at the API level. In addition need to look into the processing of merges - perhaps deferring merge processing to the end of the import. ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2003-08-24 17:22 Message: Logged In: YES user_id=176992 It now looks like the 20x speedup was a fluke result...I wish I could work out why it happened! However, using Hibernate 2.0 features, it is possible to index columns. So far, creating indexes to assist locator and subject identity point lookups have increased import time from 2.8 topics per second to 6.5 topics per second for the opera-test topic map. ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2003-08-23 08:50 Message: Logged In: YES user_id=176992 Relaxing the unique constraints on Locators gave a 20x speed increase from 1.5 topics/second to 30 topics/second for test data. ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2003-08-16 18:48 Message: Logged In: YES user_id=176992 Can also avoid import overhead by altering XTMBuilder. Currently it creates a BaseName and then incrementally adds the name string and each scope theme, causing merge checks each time. Instead, the base name string and themes should be gathered up and only turned into a base name when the first variant or the end of the base name syntax is encountered. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=704521&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:06:10
|
Feature Requests item #502434, was opened at 2002-01-11 19:00 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 >Category: Programmer Utils >Group: Next Release (example) Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Kal Ahmed (kal_ahmed) Summary: Scope Filter Initial Comment: A WalkerFilter to pass or skip associations, base names or occurrences which match a specified scope. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:04:38
|
Feature Requests item #580031, was opened at 2002-07-11 11:18 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=580031&group_id=27895 Category: Interface Improvements (example) Group: After Next Release Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Nobody/Anonymous (nobody) Summary: Allow XML in resourceData Initial Comment: Allow any arbitrary XML not in the XTM namespace to be specified as the child of an xtm:resourceData element. This could be done by simply preserving the XML in the string reported by DataObject.getData() (currently the parser drops child XML elements). It might also be useful to add an attribute to the DataObject interface which indicates the kind of data held by the object...perhaps by mime type ? ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-31 00:04 Message: Logged In: YES user_id=176992 Postpone to after 0.9.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=580031&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:03:25
|
Feature Requests item #580033, was opened at 2002-07-11 11:28 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=580033&group_id=27895 Category: None >Group: After Next Release Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Nobody/Anonymous (nobody) Summary: Simple Schema Implementation Initial Comment: Implement some simple form of topic map schema. Perhaps based on the Ontopia topic map schema language ? Whatever schema language is chosen, it should be expressed in a topic map. The implementation should allow: 1) Runtime validation - programmer can call validate(tm, schemaTM) and get a list of schema violations in tm. 2) Runtime change veto - programmer can attach a vetoable change listener to the topic map which will ensure that all changes which violate the schema raise a PropertyVetoException. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=580033&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:01:30
|
Feature Requests item #707672, was opened at 2003-03-21 18:42 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 Category: Programmer Utils Group: None Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) >Assigned to: Kal Ahmed (kal_ahmed) Summary: Canonical XTM export Initial Comment: Utility to export XTM files in canonical form as defined by Ontopia at http://www.ontopia.net/topicmaps/materials/cxtm.html ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-31 00:01 Message: Logged In: YES user_id=176992 Hmmm....now there's an idea! :-) ---------------------------------------------------------------------- Comment By: Lars Marius Garshol (larsga) Date: 2004-01-22 18:53 Message: Logged In: YES user_id=39120 It might be better to add support for the brand new canonical format defined in: ISO 13250-4: Topic Maps -- Canonicalization. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:00:38
|
Feature Requests item #502434, was opened at 2002-01-11 19:00 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 Category: None Group: None Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) >Assigned to: Kal Ahmed (kal_ahmed) Summary: Scope Filter Initial Comment: A WalkerFilter to pass or skip associations, base names or occurrences which match a specified scope. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=502434&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 00:00:16
|
Feature Requests item #636513, was opened at 2002-11-11 09:01 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=636513&group_id=27895 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) >Assigned to: Kal Ahmed (kal_ahmed) Summary: Improve export "roundtripping" Initial Comment: When importing XTM syntax, <topicRef> and <subjectIndicatorRefs> get converted to a "blank" topic with a resourceLocator and a "blank" topic with a subjectIndicator respectively. Currently XTMWriter exports these blank topics and generates internal <topicRef> elements wherever they are referenced. Add an option to XTMWriter to turn the internal topic refs to blank topics into either external <topicRef> or <subjectIndicatorRef> elements at the point(s) where those topics are referenced. ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-31 00:00 Message: Logged In: YES user_id=176992 Can now control the way such "stub" topics are written. If the property http://www.tm4j.org/tm4j/xtmwriter/writestubtopics is set to true, then the stub topics are written as <topic> elements (and the references as internal <topicRef>s, otherwise the references are written as either <subjectIndicatorRef> or <topicRef> elements and the stub topics are not written out. The default value of this property is "true", because the filtering of stub topics adds processing overhead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=636513&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-28 22:04:38
|
Feature Requests item #581622, was opened at 2002-07-15 11:39 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=581622&group_id=27895 Category: None Group: None Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) >Assigned to: Harald Kuhn (harald_kuhn) Summary: Text indexing Initial Comment: Create a simple text index implementation using Lucene. Should plug in as another standard index interface. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=581622&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-26 16:15:02
|
Bugs item #881422, was opened at 2004-01-21 14:56 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 Category: Interface (example) Group: TM4Web/Velocity 0.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: TM4Web: display of special chars broken in main display Initial Comment: hi, i am very impressed by the recent status of TMNav and TM4Web. thank you! here is a minor problem: TM4Web's display method for all topics on the main page seems broken (display works in topic.vm) in addition, TMNav displays topics only fine when (4) is used (äöü...). this behaviour does not seem to depend on using LTM char encoding headers (none = default, @"utf-8" or @"ISO-8859-1"). used versions: - tmnav-0.2.7a1-bin (alpha) - tm4web-velocity-bin-0.1-nodeps.zip my example topic: [Umlaute = "Umlaute_ä_œ_ Œ_Œ_œ_äöüß_ÄÖÜ"] i.e.: (1) ä (2) œ_ Œ (oe/OE lig) (3) Œ_œ (same) (4) äöüß_ÄÖÜ results: -------- TMNav: (4) ok TM4Web: Main page with all topics: none working (4) looks like UTF-8 viewed in ISO-8859-1 topic.vm: (1), (2), (3) ok alex -- Alexander Sigel, M.A. U Cologne, Dept. for Information Systems & Information Management si...@wi... http://wim.uni-koeln.de/ phone +49 221 470-5322 Pohligstr. 1, Room 406, 50969 Köln, GERMANY --- ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-26 16:15 Message: Logged In: YES user_id=176992 All pages generated by TM4Web/Velocity should be UTF-8 encoded. I think this might be a Tomcat problem that you are seeing. You don't say which servlet container you are using, but Tomcat 4.1.29 does not set the HTTP headers specifying content encoding properly. I have found that everything is fine with Tomcat 4.1.27. Can you check this out and let me know if the problem is still there with the older version of Tomcat ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-26 16:11:29
|
Bugs item #830520, was opened at 2003-10-26 15:11 Message generated for change (Settings changed) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=830520&group_id=27895 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Florian G. Haas (haasfg) >Assigned to: Kal Ahmed (kal_ahmed) Summary: TM4J API won't compile cleanly on pre-1.4 JDK versions Initial Comment: I don't recall pre-JDK 1.4 session being officially dropped for TM4J, but a few classes contain code that won't compile on JDK 1.3. Specifically, this is related to "root causes" for exceptions and the String class's replaceAll() method, both of which were introduced in JDK 1.4. There is only one additional invocation in the API classes that does compile on 1.3, but not 1.2.2, this being an uncaught IOException in the constructor of FileOutputStream. So on the whole it shouldn't be infeasible to extend backwards compatibility, at least for the basic TM4J API, back to JDK 1.2.2. Side note: needless to say, compiling on pre-1.4 does require that the XML-related libraries are available on the classpath. ---------------------------------------------------------------------- Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-26 16:10 Message: Logged In: YES user_id=176992 Removed most JDK 1.4-specific stuff. But some error handling for the Ozone backend relies on being able to get at the "stack" of nested exceptions. I'm not sure if there is a clean way around this. It might be that TM4J will have to require JDK1.4 for the Ozone backend. ---------------------------------------------------------------------- Comment By: Florian G. Haas (haasfg) Date: 2003-10-26 15:16 Message: Logged In: YES user_id=291928 "I don't recall pre-JDK 1.4 session" was of course meant to be "I don't recall pre-JDK 1.4 support". What was I thinking? :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=830520&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-26 16:10:46
|
Bugs item #830520, was opened at 2003-10-26 15:11 Message generated for change (Comment added) made by kal_ahmed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=830520&group_id=27895 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Florian G. Haas (haasfg) Assigned to: Nobody/Anonymous (nobody) Summary: TM4J API won't compile cleanly on pre-1.4 JDK versions Initial Comment: I don't recall pre-JDK 1.4 session being officially dropped for TM4J, but a few classes contain code that won't compile on JDK 1.3. Specifically, this is related to "root causes" for exceptions and the String class's replaceAll() method, both of which were introduced in JDK 1.4. There is only one additional invocation in the API classes that does compile on 1.3, but not 1.2.2, this being an uncaught IOException in the constructor of FileOutputStream. So on the whole it shouldn't be infeasible to extend backwards compatibility, at least for the basic TM4J API, back to JDK 1.2.2. Side note: needless to say, compiling on pre-1.4 does require that the XML-related libraries are available on the classpath. ---------------------------------------------------------------------- >Comment By: Kal Ahmed (kal_ahmed) Date: 2004-01-26 16:10 Message: Logged In: YES user_id=176992 Removed most JDK 1.4-specific stuff. But some error handling for the Ozone backend relies on being able to get at the "stack" of nested exceptions. I'm not sure if there is a clean way around this. It might be that TM4J will have to require JDK1.4 for the Ozone backend. ---------------------------------------------------------------------- Comment By: Florian G. Haas (haasfg) Date: 2003-10-26 15:16 Message: Logged In: YES user_id=291928 "I don't recall pre-JDK 1.4 session" was of course meant to be "I don't recall pre-JDK 1.4 support". What was I thinking? :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=830520&group_id=27895 |
|
From: SourceForge.net <no...@so...> - 2004-01-22 18:53:14
|
Feature Requests item #707672, was opened at 2003-03-21 19:42 Message generated for change (Comment added) made by larsga You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 Category: Programmer Utils Group: None Status: Open Priority: 5 Submitted By: Kal Ahmed (kal_ahmed) Assigned to: Nobody/Anonymous (nobody) Summary: Canonical XTM export Initial Comment: Utility to export XTM files in canonical form as defined by Ontopia at http://www.ontopia.net/topicmaps/materials/cxtm.html ---------------------------------------------------------------------- Comment By: Lars Marius Garshol (larsga) Date: 2004-01-22 19:53 Message: Logged In: YES user_id=39120 It might be better to add support for the brand new canonical format defined in: ISO 13250-4: Topic Maps -- Canonicalization. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391882&aid=707672&group_id=27895 |
|
From: Christoph F. <cf...@fo...> - 2004-01-22 09:25:10
|
Hi=20 while thinking about alex' bug report regarding the display of special chars in TMNav/TM4Web it seems to me, that technically there are three different issues. Nevertheless, I'm skating on thin ice, so please correct me if I'm wrong: > (1) ä=20 this is an html-entity. It does not have any meaning outside of html. But since it is widely used, I would like to add the resolving of html-entities as an option to the labeling mechanics of panckoucke. > (2) œ_ Œ (oe/OE lig)=20 > (3) Œ_œ (same)=20 Theese are xml(sgml?)-entities that should be resolved by the xml-parser. I would be surprised, if the ltm-parser resolves them. But maybe it should? In order to make things more convinient for the user? I tend to the opinion that panckouckes labeling mechanism shouldn't resolve theese entities, but I would be glad to hear what others think. > (4) =E4=F6=FC=DF_=C4=D6=DC=20 This enters the field of encodings. In xml this issue should be handled by the parser. I don't know whether the ltm-parser considers the encoding attribute of the source file but since alex reported that TMNav presents theese chars correctly, I assume, that the encoding is already taken into account by the ltm parser. does that make sense? bye=20 c =20 > =20 > results:=20 > --------=20 > TMNav:=20 > (4) ok=20 > =20 > TM4Web:=20 > Main page with all topics: none working=20 > (4) looks like UTF-8 viewed in ISO-8859-1=20 > topic.vm: (1), (2), (3) ok=20 > =20 > alex=20 --=20 Christoph Froehlich <cf...@fo...> |
|
From: Kal A. <ka...@te...> - 2004-01-22 09:01:51
|
Hi Cristoph, I agree with moving the core and api packages up to org.tm4j.panckoucke - that matches the package structure for TM4J as well so it keeps everything nicely consistent. Cheers, Kal On Thu, 2004-01-22 at 08:47, Christoph Froehlich wrote: > Hi panckoucke-developers > > currently the panckoucke code is organised in three main branches: > [1] org.tm4j.panckoucke.core > [2] org.tm4j.panckoucke.api > [3] org.tm4j.panckoucke.impl > > [1] and [2] contain the public api, mostly interfaces , while [3] > contains the concrete implementation. > > The difference between [1] and [2] has historical reasons and does not > make any sense at all. Therefore I would like to combine [1] and [2] > into one branch before the first non-development release of panckoucke. > > Regarding the naming, I see two options: > [a] shift all classes in [1] and [2] one level up, which means that we > get rid of both "api" as well as "core". > [b] use org.tm4j.panckoucke.api > > I tend to favour [a] but I would be glad to hear what others think. > > Actually implementing the change means that *any* app that currently > uses panckoucke will be broken and must be refactored in order to > reflect the new package structure. > > If anyone objects, please raise your hand. > > bye > c > > -- Kal Ahmed <ka...@te...> techquila |
|
From: Christoph F. <cf...@fo...> - 2004-01-22 08:47:56
|
Hi panckoucke-developers currently the panckoucke code is organised in three main branches: [1] org.tm4j.panckoucke.core [2] org.tm4j.panckoucke.api [3] org.tm4j.panckoucke.impl [1] and [2] contain the public api, mostly interfaces , while [3] contains the concrete implementation. The difference between [1] and [2] has historical reasons and does not make any sense at all. Therefore I would like to combine [1] and [2] into one branch before the first non-development release of panckoucke. Regarding the naming, I see two options: [a] shift all classes in [1] and [2] one level up, which means that we get rid of both "api" as well as "core". [b] use org.tm4j.panckoucke.api I tend to favour [a] but I would be glad to hear what others think. Actually implementing the change means that *any* app that currently uses panckoucke will be broken and must be refactored in order to reflect the new package structure. If anyone objects, please raise your hand. bye c -- Christoph Froehlich <cf...@fo...> |
|
From: SourceForge.net <no...@so...> - 2004-01-21 14:56:38
|
Bugs item #881422, was opened at 2004-01-21 06:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 Category: Interface (example) Group: TM4Web/Velocity 0.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: TM4Web: display of special chars broken in main display Initial Comment: hi, i am very impressed by the recent status of TMNav and TM4Web. thank you! here is a minor problem: TM4Web's display method for all topics on the main page seems broken (display works in topic.vm) in addition, TMNav displays topics only fine when (4) is used (äöü...). this behaviour does not seem to depend on using LTM char encoding headers (none = default, @"utf-8" or @"ISO-8859-1"). used versions: - tmnav-0.2.7a1-bin (alpha) - tm4web-velocity-bin-0.1-nodeps.zip my example topic: [Umlaute = "Umlaute_ä_œ_ Œ_Œ_œ_äöüß_ÄÖÜ"] i.e.: (1) ä (2) œ_ Œ (oe/OE lig) (3) Œ_œ (same) (4) äöüß_ÄÖÜ results: -------- TMNav: (4) ok TM4Web: Main page with all topics: none working (4) looks like UTF-8 viewed in ISO-8859-1 topic.vm: (1), (2), (3) ok alex -- Alexander Sigel, M.A. U Cologne, Dept. for Information Systems & Information Management si...@wi... http://wim.uni-koeln.de/ phone +49 221 470-5322 Pohligstr. 1, Room 406, 50969 Köln, GERMANY --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=391879&aid=881422&group_id=27895 |
153 messages has been excluded from this view by a project administrator.
