tm4j-developers — Forum for issues related to development of TM4J.

RE: [Tm4j-developers] strange labels in TMNav 0.2.9(pre1)

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

Christoph Froehlich wrote:

> > "foo [org.tm4j.topicmap.memory.TopicImpl@f60dla08]"
> this is a flaw in panckoucke. It calls toString() on the set=20
> of scoping
> topics of the basename. I changed it to display a more=20
> meaningful name.
>=20
> This will be part of the next release of panckoucke. If you need it
> badly, please either compile panckoucke from cvs or drop me a=20
> line and I
> will send you a compiled version via private mail

Yay! Thanks for that Christoph. I built the panckoucke jar from source =
and it does look much better now. I've added subject indicators to my =
harvester so I can see those (si) nodes floating around now too - and =
I'm very happy with it. :-)

Con

[Tm4j-developers] [ tm4j-Bugs-1035020 ] XTMBuilder should accept misplaced <scope> elements.

[SourceForge.net <no...@so...>]

Bugs item #1035020, was opened at 2004-09-26 14:57
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035020&group_id=27895

Category: Import/Export
Group: TM4J 0.9.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: XTMBuilder should accept misplaced <scope> elements.

Initial Comment:
The XTMBuilder should be able to handle a <scope>
element appearing in the wrong position as a child of
<association>, <baseName> and <occurrence> elements
when DTD validation is disabled.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 20:31

Message:
Logged In: YES 
user_id=176992

Added a test for various lax parsing features such as
out-of-order scope and instanceOf elements. The parser is
still probably not bullet-proof against invalid XTM files,
but it should accept a wider range of malformed topic maps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035020&group_id=27895

[Tm4j-developers] Concretizer

[George T. <geo...@fr...>]

Hello,

I am posting you how I am thinking to go with "Concretizer"
You can see the attacked Concretizer.java

Do you thing that something like this is OK?

Because I understend that Panckoucke is going to have a major
reconstruction,
I feel hesitated on developing, before relative discussions.

This that I don't know is, if you you feel that "Concretizer" should be able
to edit
RDF together with "Topic Maps" and should have some common API for
all of these technologies.

Thank you very much
Giorgos


____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.

[Tm4j-developers] [ tm4j-Bugs-973979 ] Exception when creating two topics with the same base name

[SourceForge.net <no...@so...>]

Bugs item #973979, was opened at 2004-06-16 17:08
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

Category: Hibernate Impl
Group: TM4J 0.9.6
>Status: Pending
>Resolution: Rejected
Priority: 7
Submitted By: Andy Peel (atpeel)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Exception when creating two topics with the same base name

Initial Comment:
If I create two topics with the same base name, I get
this exception:

Message:
testUpdateTopic_SameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  syntax error at
or near "topic_types" at character 15
Cause:ERROR:  syntax error at or near "topic_types" at
character 15

The problem seems to be inside
org.tm4j.topicmap.hibernate.TopicImpl.replaceTopicReference()
where the SQL query generated includes the fragment
"update ignore". The ignore keyword only seems to work
on BDB/MySQl, whereas I'm using PostgreSQL.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 15:18

Message:
Logged In: YES 
user_id=176992

The flush is actually superfluous now. Under a previous
version of Hibernate, the default Hibernate flushing code
was not flushing updates before doing a query. This seems to
be fixed with the current version of Hibernate, so those
flushes could probably be removed.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-15 15:05

Message:
Logged In: YES 
user_id=1064816

It turns out that the problem was that our
HibernateSpoofTransactionManager was swallowing the explicit
flush calls made by TM4J. We've also tested this for
transaction isolation correctness and it's fine.

Can you shed some light on why the flush is needed?

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 13:37

Message:
Logged In: YES 
user_id=176992

I have successfully replicated this problem with the early
commit. Even when unecessary session.flush() calls are
removed, a commit still occurs before any query. If you
write code like:
Topic t = tm.createTopic("topic1);
BaseName bn = tm.createName("bn1");

The row for the Topic gets committed just before the system
checks the id "bn1" is not a duplicate ID. It looks like the
Hibernate code needs to be reviewed for transaction isolation.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-13 16:13

Message:
Logged In: YES 
user_id=1064816

Time passes...

OK, having reopened this at our end to try and get to the
bottom of it, it seems that the test I wrote to test Kal's
fix had a bug in it...
The bug in the test has now been fixed and we can reproduce
the problem that I got before. The exception I sent Kal in a
private email was as follows:


Message:
testUpdateTopicSameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  update or delete on
"tmobjects" violates foreign key constraint
"fkce45afe9c6f0e22b" on "topic_sips"
Cause:ERROR:  update or delete on "tmobjects" violates
foreign key constraint "fkce45afe9c6f0e22b" on "topic_sips"


We have tried running the code *without* our custom
transaction manager code, and calling
provider.openTransaction() instead. Our test then passes
fine and I can create two topics with the same base name
that are then merged inside TM4J. Our custom transaction
provider mechanism basically subclasses Hibernate's
SessionFactory and Session classes with spoof versions that
are wired into a simple transaction manager that forces the
use of a single transaction per thread (analagous to
Hibernate's Session-In-View pattern).

This is different to the way the transaction opened by
calling provider.openTransaction() works. By putting some
breakpoints into our test we found that every time we create
a topic and set its base name, the transaction's commit
method is called 4 times - you can actually see the data
being inserted into the tmobjects table as you step through
the code. This really needs to be done atomically, in a
single transaction.

Of course if you don't use a custom transaction provider and
you don't call provider.openTransaction() then TM4J creates
and commits a transaction for each operation is performs
internally.

So it looks like it's the fact that the TM4J-managed
transaction is being committed too early is preventing the
topic_sips foreign key violation from happening.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-22 16:59

Message:
Logged In: YES 
user_id=1064816

This works fine when I test it with stand-alone code,
although I still have problems when I run within my code base. 

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-18 18:28

Message:
Logged In: YES 
user_id=176992

Fixed error in the static merging code that caused this
exception. Waiting on confirmation that the fix actually
works on PostgreSQL...

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-17 20:13

Message:
Logged In: YES 
user_id=176992

Sorry, I misunderstood the problem. I need to take a closer
look at that SQL update. I used SQL directly for this
operation for perfomance, but my simple update statement can
violate key constraints (especially when merging on names or
subject indicators I think). I *think* that there must be a
way to do what I want without temporarily violating key
constraints.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-17 10:11

Message:
Logged In: YES 
user_id=1064816

Hi Kal,

I'm pretty sure that won't make a difference - the SQL query
in TopicImpl includes the IGNORE keyword, and as far as I
can make out, that only works with BDB/MySQL. I even tried
the query directly using psql, but to no avail.


Andy.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-16 19:10

Message:
Logged In: YES 
user_id=176992

I wonder if this is a Hibernate problem. There was a new
Hibernate release on June 1st (2.1.4) - perhaps it is worth
giving that a spin to see if the Postgres problem got fixed ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1035301 ] SerializedTopicMapSource ignoring xml:base

[SourceForge.net <no...@so...>]

Bugs item #1035301, was opened at 2004-09-27 08:31
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

Category: Import/Export
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: SerializedTopicMapSource ignoring xml:base

Initial Comment:
When reading an XTM file using
SerializedTopicMapSource, it appears that the value of
an xml:base attribute on the document root element is
not being assigned to the topic map.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 17:00

Message:
Logged In: YES 
user_id=176992

Update:

Up to now TM4J has used the xml:base attribute only for
resolving references to other documents. Same-document
reference (#foo) and element IDs are resolved against the
source locator of the topic map file being read. This is (I
believe) in line with the original position of the ISO
committee. However, RDF does it a different way and resolves
RDF:ID attributes and same-document references against the
xml:base value - and in a lot of ways that makes more sense.

I've put a query about this in to the ISO working group.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1015061 ] Wrong example for ozone provider config

[SourceForge.net <no...@so...>]

Bugs item #1015061, was opened at 2004-08-24 09:04
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1015061&group_id=27895

Category: Documentation
Group: TM4J 0.9.6
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Wrong example for ozone provider config

Initial Comment:
kal,

in docs/devguide/ch03s05.html#config.ozone you write in
example 3.4 that the config property should be

dburl=ozone:remote://localhost:3333

according to what you write above and my experiences
here, this should be changed to 

ozonedb:remote://localhost:3333

note the "ozone_db_", or things go havoc. could be that
further down, the same applies to
dburl=ozone:local:/data/ozone/topicmaps ?

this prob showed up with the current tmnav, no other
experiences available (yet).

greets, tobi... :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1015061&group_id=27895

Re: [Tm4j-developers] strange labels in TMNav 0.2.9(pre1)

[Christoph F. <cf...@fo...>]

Hi Conal

thanks for your ongoing reviews. I appreciate them very much.


Am Mo, den 27.09.2004 schrieb Conal Tuohy um 4:13:
> I've been using TMNav to visualise my topic map. It's great, but
> there's one little thing about it that bugs me: the labels. 
> 
> A topic with id "foo-topic-id" but no name gets a label like:
> 
> "T [foo-topic-id]" 
> 
> That seems perfectly reasonable. I don't know why, but a topic which
> has a name will display differently: e.g. a topic with the name "foo"
> gets a label like: 
> 
> "foo [org.tm4j.topicmap.memory.TopicImpl@f60dla08]"
this is a flaw in panckoucke. It calls toString() on the set of scoping
topics of the basename. I changed it to display a more meaningful name.

This will be part of the next release of panckoucke. If you need it
badly, please either compile panckoucke from cvs or drop me a line and I
will send you a compiled version via private mail

bye
c



bye

c



The last part of the label looks like the result of calling toString()
on the topic object. IMHO it's not worth having; it just clutters up the
display. :-) But I don't know where to start changing it.
> 
> version info:
> TMNav - Version: TMNav 0.2.9(pre1 )*
> Panckoucke - Version: Panckoucke 0.3.2(alpha)
> 
> Cheers
> 
> Con
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement
> on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Christoph Froehlich <cf...@fo...>

[Tm4j-developers] [ tm4j-Bugs-1012130 ] ValuePredicate ignores Variants

[SourceForge.net <no...@so...>]

Bugs item #1012130, was opened at 2004-08-19 12:47
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1012130&group_id=27895

Category: Tolog engine
Group: TM4J 0.9.6
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Lars Heuer (lheuer)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: ValuePredicate ignores Variants

Initial Comment:
Acc. to the tolog specification the value predicate
queries topicnames, occurrences and variants for the
given value. 
In tologx only topicnames and occurrences are queries
for the value. 

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-27 15:34

Message:
Logged In: YES 
user_id=176992

Checked in fix for 0.9.7 release

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-08-22 17:19

Message:
Logged In: YES 
user_id=176992

Requires implementation of VariantDataIndex (and
VariantLocatorIndex).

----------------------------------------------------------------------

Comment By: Lars Heuer (lheuer)
Date: 2004-08-19 12:50

Message:
Logged In: YES 
user_id=399396

Additional comment: Problem is the "matchObject" method, all
other methods work, IMO. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1012130&group_id=27895

RE: [Tm4j-developers] configuring in-memory topic map providerbase locator

[Conal T. <co...@pa...>]

Kal Ahmed wrote:

> I'll have to look into why the xml:base attribute is not affecting the
> base locator of the topic map (I have a suspicion that it is
> to do with
> the way that the SerializedTopicMapSource works).

That's definitely the case. I was looking at the source code just an hour
ago, and it was certainly the case then :-)

The SerializedTopicMapSource constructor which I used was passed a single
java.io.File. It converts this to a url in a String variable, and in
populateTopicMap it makes it into a locator, and in readMap it passes the
locator to the builder.build method. My guess is that the builder should
over-ride this supplied base-locator if it finds another one in the XTM
stream itself (in the form of an xml:base attribute).

> What you suggest
> (adding a base attribute to the <import> element) is a good idea as a
> workaround.

OK. I might do that.

> Another possible workaround is to make use of a catalog file. TM4J
> supports redirection through a catalog, so you can specify that the
> filesystem location for topic map http://foo.xtm is
> /path/to/xtmfile.xtm. The http:// URI will be used as the topic maps
> base locator even thought the topic map is read from the local
> filesystem.

Actually this sounds like a neat trick too :-) Thanks heaps!

> So there are a lot of options, but I agree that we should fix the
> xml:base processing for the simple case where a
> SerializedTopicMapSource
> reads a single XTM file.

Cheers

Con

[Tm4j-developers] [ tm4j-Bugs-1035301 ] SerializedTopicMapSource ignoring xml:base

[SourceForge.net <no...@so...>]

Bugs item #1035301, was opened at 2004-09-27 08:31
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

>Category: Import/Export
>Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
>Assigned to: Kal Ahmed (kal_ahmed)
Summary: SerializedTopicMapSource ignoring xml:base

Initial Comment:
When reading an XTM file using
SerializedTopicMapSource, it appears that the value of
an xml:base attribute on the document root element is
not being assigned to the topic map.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1035301 ] SerializedTopicMapSource ignoring xml:base

[SourceForge.net <no...@so...>]

Bugs item #1035301, was opened at 2004-09-27 08:31
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=1035301&group_id=27895

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Nobody/Anonymous (nobody)
Summary: SerializedTopicMapSource ignoring xml:base

Initial Comment:
When reading an XTM file using
SerializedTopicMapSource, it appears that the value of
an xml:base attribute on the document root element is
not being assigned to the topic map.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035301&group_id=27895

Re: [Tm4j-developers] configuring in-memory topic map provider base locator

[Kal A. <ka...@te...>]

Hi Conal,

I'll have to look into why the xml:base attribute is not affecting the
base locator of the topic map (I have a suspicion that it is to do with
the way that the SerializedTopicMapSource works). What you suggest
(adding a base attribute to the <import> element) is a good idea as a
workaround.

Another possible workaround is to make use of a catalog file. TM4J
supports redirection through a catalog, so you can specify that the
filesystem location for topic map http://foo.xtm is
/path/to/xtmfile.xtm. The http:// URI will be used as the topic maps
base locator even thought the topic map is read from the local
filesystem.

So there are a lot of options, but I agree that we should fix the
xml:base processing for the simple case where a SerializedTopicMapSource
reads a single XTM file.

Cheers,

Kal

On Mon, 2004-09-27 at 07:16, Conal Tuohy wrote:
> I am using the In-Memory topic map provider with Cocoon.
> 
> I need to load the topic map from an XTM file into memory, but I want to give it a different base locator. I want the base locator of the resulting map to be an http url, but I want to read the file from the local file system. I thought I could specify an xml:base attribute on the topicMap element in the file, but this has no effect, and I end up with a topic map with a base locator of "file:// etc". 
> 
> I've had a look at the Cocoon TopicMapManagerComponent code, and there seems to be a couple of ways to specify a source in the cocoon.xconf file: using a parameter called "tm4j.topicmap.0", or alternatively, using an <import> element. I haven't yet looked at the first method ("tm4j.topicmap.0 parameter") in great detail, but it doesn't seem to offer what I want. Neither does the <import> element :-) but it's what I've been using so far. It looks like this:
> 
> <import name="nzetc" file="/nzetc/tm/export/nzetc.xtm"/>
> 
> The TopicMapManagerComponent has a method configureImport which processes this:
> 
>    private void configureImport(TopicMapProvider provider, Configuration imp) throws ConfigurationException
>     {
>         String file = imp.getAttribute(CONFIG_IMPORT_FILE);
>         String name = imp.getAttribute(CONFIG_IMPORT_NAME);
>         String realPath = m_context.getRealPath(file);
>         File f = new File(realPath);
>         try {
>             SerializedTopicMapSource tmSrc = new SerializedTopicMapSource(f);
>             TopicMap tm = provider.addTopicMap(tmSrc);
>             m_topicMapNames.put(name, tm.getBaseLocator());
>         } catch (Exception ex) {
>             getLogger().error("TopicMapManagerComponent: Unable to process import named " + name, ex );
>             throw new ConfigurationException("Unable to process import '" + name + "'", ex);
>         }
>     }
> 
> ... so the base locator is set by the SerializedTopicMapSource, which makes the locator by converting the java.io.File to a URL, so my base locator always equals the URL of the file where I loaded the XTM from:
> 
>    locatorString = file.toURL().toString();
> 
> If this seems like a reasonable requirement (to be able to specify a different base locator), I'd like to change the TopicMapManagerComponent to read a "base" attribute from the <import> element and pass this to the SerializedTopicMapSource constructor along with the file.
> 
> e.g.
> 
> <import name="nzetc" base="http://www.nzetc.org/tm/nzetc.xtm" file="/nzetc/tm/export/nzetc.xtm"/>
> 
> In the TopicMapManagerComponent this would be something like:
> 
>    private void configureImport(TopicMapProvider provider, Configuration imp) throws ConfigurationException
>     {
>         String file = imp.getAttribute(CONFIG_IMPORT_FILE);
>         String name = imp.getAttribute(CONFIG_IMPORT_NAME);
>         String base = imp.getAttribute(CONFIG_IMPORT_BASE); // need to add this field
>         String realPath = m_context.getRealPath(file);
>         File f = new File(realPath);
>         try {
>             baseLocator = provider.getLocatorFactory().createLocator("URI", base); // convert to locator
>             SerializedTopicMapSource tmSrc = new SerializedTopicMapSource(f, baseLocator); // set base locator
>             TopicMap tm = provider.addTopicMap(tmSrc);
>             m_topicMapNames.put(name, tm.getBaseLocator());
>         } catch (Exception ex) {
>             getLogger().error("TopicMapManagerComponent: Unable to process import named " + name, ex );
>             throw new ConfigurationException("Unable to process import '" + name + "'", ex);
>         }
>     }
> 
> Alternatively, the SerializedTopicMapSource could parse the source and extract the xml:base attribute and use that. In some ways this would be preferable.
> 
> What do other people think?
> 
> Sorry for the long email. I'm not even sure if this is a good idea, but it's related to a problem I'm having with subject indicators, which I'll post about on the users list.
> 
> Cheers
> 
> Con
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] configuring in-memory topic map provider base locator

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

I am using the In-Memory topic map provider with Cocoon.

I need to load the topic map from an XTM file into memory, but I want to =
give it a different base locator. I want the base locator of the =
resulting map to be an http url, but I want to read the file from the =
local file system. I thought I could specify an xml:base attribute on =
the topicMap element in the file, but this has no effect, and I end up =
with a topic map with a base locator of "file:// etc".=20

I've had a look at the Cocoon TopicMapManagerComponent code, and there =
seems to be a couple of ways to specify a source in the cocoon.xconf =
file: using a parameter called "tm4j.topicmap.0", or alternatively, =
using an <import> element. I haven't yet looked at the first method =
("tm4j.topicmap.0 parameter") in great detail, but it doesn't seem to =
offer what I want. Neither does the <import> element :-) but it's what =
I've been using so far. It looks like this:

<import name=3D"nzetc" file=3D"/nzetc/tm/export/nzetc.xtm"/>

The TopicMapManagerComponent has a method configureImport which =
processes this:

   private void configureImport(TopicMapProvider provider, Configuration =
imp) throws ConfigurationException
    {
        String file =3D imp.getAttribute(CONFIG_IMPORT_FILE);
        String name =3D imp.getAttribute(CONFIG_IMPORT_NAME);
        String realPath =3D m_context.getRealPath(file);
        File f =3D new File(realPath);
        try {
            SerializedTopicMapSource tmSrc =3D new =
SerializedTopicMapSource(f);
            TopicMap tm =3D provider.addTopicMap(tmSrc);
            m_topicMapNames.put(name, tm.getBaseLocator());
        } catch (Exception ex) {
            getLogger().error("TopicMapManagerComponent: Unable to =
process import named " + name, ex );
            throw new ConfigurationException("Unable to process import =
'" + name + "'", ex);
        }
    }

... so the base locator is set by the SerializedTopicMapSource, which =
makes the locator by converting the java.io.File to a URL, so my base =
locator always equals the URL of the file where I loaded the XTM from:

   locatorString =3D file.toURL().toString();

If this seems like a reasonable requirement (to be able to specify a =
different base locator), I'd like to change the TopicMapManagerComponent =
to read a "base" attribute from the <import> element and pass this to =
the SerializedTopicMapSource constructor along with the file.

e.g.

<import name=3D"nzetc" base=3D"http://www.nzetc.org/tm/nzetc.xtm" =
file=3D"/nzetc/tm/export/nzetc.xtm"/>

In the TopicMapManagerComponent this would be something like:

   private void configureImport(TopicMapProvider provider, Configuration =
imp) throws ConfigurationException
    {
        String file =3D imp.getAttribute(CONFIG_IMPORT_FILE);
        String name =3D imp.getAttribute(CONFIG_IMPORT_NAME);
        String base =3D imp.getAttribute(CONFIG_IMPORT_BASE); // need to =
add this field
        String realPath =3D m_context.getRealPath(file);
        File f =3D new File(realPath);
        try {
            baseLocator =3D =
provider.getLocatorFactory().createLocator("URI", base); // convert to =
locator
            SerializedTopicMapSource tmSrc =3D new =
SerializedTopicMapSource(f, baseLocator); // set base locator
            TopicMap tm =3D provider.addTopicMap(tmSrc);
            m_topicMapNames.put(name, tm.getBaseLocator());
        } catch (Exception ex) {
            getLogger().error("TopicMapManagerComponent: Unable to =
process import named " + name, ex );
            throw new ConfigurationException("Unable to process import =
'" + name + "'", ex);
        }
    }

Alternatively, the SerializedTopicMapSource could parse the source and =
extract the xml:base attribute and use that. In some ways this would be =
preferable.

What do other people think?

Sorry for the long email. I'm not even sure if this is a good idea, but =
it's related to a problem I'm having with subject indicators, which I'll =
post about on the users list.

Cheers

Con

[Tm4j-developers] strange labels in TMNav 0.2.9(pre1)

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

I've been using TMNav to visualise my topic map. It's great, but there's =
one little thing about it that bugs me: the labels.=20

A topic with id "foo-topic-id" but no name gets a label like:

"T [foo-topic-id]"=20

That seems perfectly reasonable. I don't know why, but a topic which has =
a name will display differently: e.g. a topic with the name "foo" gets a =
label like:=20

"foo [org.tm4j.topicmap.memory.TopicImpl@f60dla08]"

The last part of the label looks like the result of calling toString() =
on the topic object. IMHO it's not worth having; it just clutters up the =
display. :-) But I don't know where to start changing it.

version info:
TMNav - Version: TMNav 0.2.9(pre1 )*
Panckoucke - Version: Panckoucke 0.3.2(alpha)

Cheers

Con

[Tm4j-developers] [ tm4j-Feature Requests-1035034 ] Allow regexp selection of topic maps in <topicmaps> element

[SourceForge.net <no...@so...>]

Feature Requests item #1035034, was opened at 2004-09-26 15:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1035034&group_id=27895

Category: tm4web/velocity
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Allow regexp selection of topic maps in <topicmaps> element

Initial Comment:
Allow a regular expression to be used to specify the
source locator(s) of the topic maps to be loaded by a
<topicmaps> element in the configuration file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1035034&group_id=27895

[Tm4j-developers] [ tm4j-Feature Requests-1035033 ] Allow topic template overrides inside <topicmaps> element

[SourceForge.net <no...@so...>]

Feature Requests item #1035033, was opened at 2004-09-26 15:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1035033&group_id=27895

Category: tm4web/velocity
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Allow topic template overrides inside <topicmaps> element

Initial Comment:
Extend the configuration file format to allow topic
template configuration to appear inside the <topicmaps>
element and apply to all topicmaps imported/specified
by the <topicmaps> element.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391882&aid=1035033&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1035020 ] XTMBuilder should accept misplaced <scope> elements.

[SourceForge.net <no...@so...>]

Bugs item #1035020, was opened at 2004-09-26 14:57
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=1035020&group_id=27895

Category: Import/Export
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Kal Ahmed (kal_ahmed)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: XTMBuilder should accept misplaced <scope> elements.

Initial Comment:
The XTMBuilder should be able to handle a <scope>
element appearing in the wrong position as a child of
<association>, <baseName> and <occurrence> elements
when DTD validation is disabled.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1035020&group_id=27895

[Tm4j-developers] RE: [TM4J-users] differently-scoped names causing a merge?

[Kal A. <ka...@te...>]

Hi Conal,

Thanks for the update. I agree that XTMBuilder should either flag up a
misplaced <scope> element as an error or process it, but it should
definitely not just silently ignore it. There is an optional flag which
turns on XTM validation: http://www.tm4j.org/tm4j/xtmbuilder/validation
which you set by calling the setProperty method of XTMBuilder (although
this gets hidden from you if you use the SerializedTopicMapSource
helper).

Following the maxim "Be strict in what you produce and generous in what
you accept", I think that the builder should be able to handle a <scope>
element appearing in the wrong place as a child of <baseName>,
<occurrence> and <association> - so I'll enter a bug for this into the
tracker.

Cheers,

Kal

On Sun, 2004-09-26 at 08:06, Conal Tuohy wrote:
> I think I've found what was going wrong with my topicmaps (in which the name
> scopes were being ignored).
> 
> I debugged org.tm4j.topicmap.utils.XTMBuilder and found that for a baseName
> to be scoped, the scope element has to appear before the baseNameString
> element. Looking at the DTD, this is of course perfectly correct - the
> optional <scope> child of a <baseName> must be the first child element. So
> it was my mistake. D'oh! :-(
> 
> But it seems to me that it'd be nice for XTMBuilder to flag a <scope>
> appearing after a <baseNameString> as an error, rather than ignoring it. The
> scoping of <occurrence> and <association> elements is handled differently,
> and for these elements XTMBuilder seems to accept <scope> elements which
> appear (invalidly) after a <resourceData>, <member>, etc,
> 
> Cheers
> 
> Con
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tm4j-users mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-users
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] RE: [TM4J-users] differently-scoped names causing a merge?

[Conal T. <co...@pa...>]

I think I've found what was going wrong with my topicmaps (in which the name
scopes were being ignored).

I debugged org.tm4j.topicmap.utils.XTMBuilder and found that for a baseName
to be scoped, the scope element has to appear before the baseNameString
element. Looking at the DTD, this is of course perfectly correct - the
optional <scope> child of a <baseName> must be the first child element. So
it was my mistake. D'oh! :-(

But it seems to me that it'd be nice for XTMBuilder to flag a <scope>
appearing after a <baseNameString> as an error, rather than ignoring it. The
scoping of <occurrence> and <association> elements is handled differently,
and for these elements XTMBuilder seems to accept <scope> elements which
appear (invalidly) after a <resourceData>, <member>, etc,

Cheers

Con

[Tm4j-developers] relating Panckoucke development

[George T. <geo...@fr...>]

Hello,

The Panckoucke, as it is now, allows the Panckoucke user to access
TopicMapObject(s) that belong in TM4J below.

I would like to ask you, if you have discussed about this thing,
and if you already concluded if this sould be continued, or Panckoucke
should "cover" TM4J completely.

There is not an obvious choise for me, especialy when Topic Map Editing
comes into play.

Cheers
Giorgos


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.767 / Virus Database: 514 - Release Date: 21/9/2004


____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.

Re: [Tm4j-developers] Future of Panckoucke 2

[George T. <geo...@fr...>]

Hello all,
I am reading all your thoughts for some days now
I don't realy understend how Panckoucke could handle something so general.
(Topic Maps, RDF, TM4J, Jena, ?)
Personaly, I am interested mainly in Topic Maps, not in RDF or other things
and as soon as Panckoucke continues to improve "Topic Map handling" I will
be happy,
and I'll try to help it in this direction. :-)
I am still very new here, but I hope I will stay long.

Cheers
Giorgos


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.745 / Virus Database: 497 - Release Date: 27/8/2004


____________________________________________________________________
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.

Re: [Tm4j-developers] Future of Panckoucke 2

[Christoph F. <cf...@fo...>]

Hi Harald,

(Since you did write in english, I assume that the mail was accidently
send to me off-list)
  
I'm really happy that it was a misunderstanding and the we have the same
intentions with panckoucke.

I agree absolutely with what you are saying below, especially with your
list of common points. 



Bye
c

 

Am Do, den 16.09.2004 schrieb Harald Kuhn um 17:30:
> Hi Christoph,
> 
> >Hi Harald,
> >
> >I go with you, that it would be great to extend the scope of panckoucke
> >o 'abstract' data from other technologies than topicmaps. RDF for
> >Example.
> >
> >And it's comprehensible, from a technical point of view, to make this
> >next generation panckoucke a project of its own.
> >
> >I have also strong objections against this, regarding the distraction of
> >the community, but since panckoucke is the module that has the lowest
> >attention on the tm4j-mailing lists, we maybe could risk it. 
> 
> That is quite true. Moreover, i do not think that even if some of us would move panckoucke to another project and keep on developing it there, that we all would stop contributing to TMNav or TM4J. On the contrary, I think that it is quite well possible, that panckoucke does get much more attention as a project of its own. 
> 
> >But before we strike this path, we should come to an agreement what
> >panckoucke is about. There seems to be a major misunderstanding. I
> >*never* voted to split panckoucke in any way, especially I did not vote
> >for a separation of the model/abstractor definition on the one hand and
> >the concrete abstractor implementations on the other (at least I did not
> >want to vote for something like that. Sorry if something I said, gave
> >you that impression).
> >To me, a vital part of panckoucke is the implementations of abstractors
> >and the helpersas well, that connect engines like tm4j and maybe jena in
> >the future. 
> 
> That was indeed a misunderstanding. I thought, that you had objections in moving the abstractors into a new panckoucke. However it is good, that you clarified this, as i also think that the Abstractors are a vital part of panckoucke.
> 
> 
> >I could imagine very well that panckoucke does not implement the
> >abstract model on its own. In fact, I searched for a java-graph-api
> >implementation when starting panckoucke, but did not find one and
> >therefor implemented it by myself. This is something that I would
> >definitely like to include as a third-party lib.
> >
> >But a project that just defines the model and interfaces and leaves the
> >implementation of real and useful abstractors to others, is not what I
> >mean, when talking about panckoucke. 
> 
> As i already wrote above, i too do not really want to separate these two, but thought this to be a compromise between what you and i suggested because i did misunderstand some of what you wrote. For me panckocke is the complete Framework, the Store API, the Abstractors, the model,  and the renderers which create a visualisation from it. 
> 
> >Maybe it is a project of its own and panckoucke could use it?
> >
> >What do you think?
> 
> I do not think that such a project would stand a chance at all. The real innovation of panckouck is, that it does not just define a GraphAPI, some algorithms and renderers, but that it does provide a complete framework which starts with as soon as handling asynchronous loading. There are about a dozen Graph Frameworks out there, so just define another one is probably not going to persuade anyone to use it. And a graph project which is only used by panckoucke and only developed by some of the panckoucke developers would IMHO make things only more complicated without any real gain. 
> 
> >Bye
> >c
> 
> I will try to collect the things (that i think) we agree on:
> 
> - panckoucke is the whole framework including everything which is part of it now
> - panckoucke should stay like this, if we move it or not
> - there is a danger of splitting the community in moving it, however as there is not that much 
>   attention for panckoucke, it may be only a small one
> 
> Cheers,
> Harald
> 
> 
> ________________________________________________________________
> Verschicken Sie romantische, coole und witzige Bilder per SMS!
> Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193
-- 
Christoph Froehlich <cf...@fo...>

Re: [Tm4j-developers] Future of Panckoucke 2

[Christoph F. <cf...@fo...>]

Hi Harald,

I go with you, that it would be great to extend the scope of panckoucke
to 'abstract' data from other technologies than topicmaps. RDF for
example.

And it's comprehensible, from a technical point of view, to make this
next generation panckoucke a project of its own.

I have also strong objections against this, regarding the distraction of
the community, but since panckoucke is the module that has the lowest
attention on the tm4j-mailing lists, we maybe could risk it. 



But before we strike this path, we should come to an agreement what
panckoucke is about. There seems to be a major misunderstanding. I
*never* voted to split panckoucke in any way, especially I did not vote
for a separation of the model/abstractor definition on the one hand and
the concrete abstractor implementations on the other (at least I did not
want to vote for something like that. Sorry if something I said, gave
you that impression).
To me, a vital part of panckoucke is the implementations of abstractors
and the helpersas well, that connect engines like tm4j and maybe jena in
the future. 


I could imagine very well that panckoucke does not implement the
abstract model on its own. In fact, I searched for a java-graph-api
implementation when starting panckoucke, but did not find one and
therefor implemented it by myself. This is something that I would
definitely like to include as a third-party lib.

But a project that just defines the model and interfaces and leaves the
implementation of real and useful abstractors to others, is not what I
mean, when talking about panckoucke. Maybe it is a project of its own,
and panckoucke could use it?

What do you think?

Bye
c


Am Di, den 14.09.2004 schrieb Harald Kuhn um 20:05: 
> Hi all,
> 
> to clearify my suggestion, what i wanted to suggest was the founding
> of a project which is somewhat like TMAPI. A Generic definition of
> interfaces (with a lightweight implementation of the Model interfaces
> - which is unlike TMAPI) and some example implementations. The
> TopicMap specific Implementations of this interfaces should (thats
> something Christoph and Jens perusaded me, i originall wanted to move
> the Abstractors as well) either stay with the TMNav and panckoucke
> projects in TM4J or should merge into the TMNav project.
> 
> Cheers
> Harald
> _________________________________________________________
> Mit WEB.DE FreePhone? mit hochster Qualitat ab 0 Ct./Min.
> weltweit telefonieren! http://freephone.web.de/?mc=021201
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
> Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
> Camcorder. More prizes in the weekly Lunch Hour Challenge.
> Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers



-- 



Christoph Froehlich <cf...@fo...>

[Tm4j-developers] [ tm4j-Bugs-973979 ] Exception when creating two topics with the same base name

[SourceForge.net <no...@so...>]

Bugs item #973979, was opened at 2004-06-16 16:08
Message generated for change (Comment added) made by atpeel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

Category: Hibernate Impl
Group: TM4J 0.9.6
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Andy Peel (atpeel)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Exception when creating two topics with the same base name

Initial Comment:
If I create two topics with the same base name, I get
this exception:

Message:
testUpdateTopic_SameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  syntax error at
or near "topic_types" at character 15
Cause:ERROR:  syntax error at or near "topic_types" at
character 15

The problem seems to be inside
org.tm4j.topicmap.hibernate.TopicImpl.replaceTopicReference()
where the SQL query generated includes the fragment
"update ignore". The ignore keyword only seems to work
on BDB/MySQl, whereas I'm using PostgreSQL.

----------------------------------------------------------------------

>Comment By: Andy Peel (atpeel)
Date: 2004-09-15 14:05

Message:
Logged In: YES 
user_id=1064816

It turns out that the problem was that our
HibernateSpoofTransactionManager was swallowing the explicit
flush calls made by TM4J. We've also tested this for
transaction isolation correctness and it's fine.

Can you shed some light on why the flush is needed?

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 12:37

Message:
Logged In: YES 
user_id=176992

I have successfully replicated this problem with the early
commit. Even when unecessary session.flush() calls are
removed, a commit still occurs before any query. If you
write code like:
Topic t = tm.createTopic("topic1);
BaseName bn = tm.createName("bn1");

The row for the Topic gets committed just before the system
checks the id "bn1" is not a duplicate ID. It looks like the
Hibernate code needs to be reviewed for transaction isolation.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-13 15:13

Message:
Logged In: YES 
user_id=1064816

Time passes...

OK, having reopened this at our end to try and get to the
bottom of it, it seems that the test I wrote to test Kal's
fix had a bug in it...
The bug in the test has now been fixed and we can reproduce
the problem that I got before. The exception I sent Kal in a
private email was as follows:


Message:
testUpdateTopicSameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  update or delete on
"tmobjects" violates foreign key constraint
"fkce45afe9c6f0e22b" on "topic_sips"
Cause:ERROR:  update or delete on "tmobjects" violates
foreign key constraint "fkce45afe9c6f0e22b" on "topic_sips"


We have tried running the code *without* our custom
transaction manager code, and calling
provider.openTransaction() instead. Our test then passes
fine and I can create two topics with the same base name
that are then merged inside TM4J. Our custom transaction
provider mechanism basically subclasses Hibernate's
SessionFactory and Session classes with spoof versions that
are wired into a simple transaction manager that forces the
use of a single transaction per thread (analagous to
Hibernate's Session-In-View pattern).

This is different to the way the transaction opened by
calling provider.openTransaction() works. By putting some
breakpoints into our test we found that every time we create
a topic and set its base name, the transaction's commit
method is called 4 times - you can actually see the data
being inserted into the tmobjects table as you step through
the code. This really needs to be done atomically, in a
single transaction.

Of course if you don't use a custom transaction provider and
you don't call provider.openTransaction() then TM4J creates
and commits a transaction for each operation is performs
internally.

So it looks like it's the fact that the TM4J-managed
transaction is being committed too early is preventing the
topic_sips foreign key violation from happening.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-22 15:59

Message:
Logged In: YES 
user_id=1064816

This works fine when I test it with stand-alone code,
although I still have problems when I run within my code base. 

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-18 17:28

Message:
Logged In: YES 
user_id=176992

Fixed error in the static merging code that caused this
exception. Waiting on confirmation that the fix actually
works on PostgreSQL...

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-17 19:13

Message:
Logged In: YES 
user_id=176992

Sorry, I misunderstood the problem. I need to take a closer
look at that SQL update. I used SQL directly for this
operation for perfomance, but my simple update statement can
violate key constraints (especially when merging on names or
subject indicators I think). I *think* that there must be a
way to do what I want without temporarily violating key
constraints.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-17 09:11

Message:
Logged In: YES 
user_id=1064816

Hi Kal,

I'm pretty sure that won't make a difference - the SQL query
in TopicImpl includes the IGNORE keyword, and as far as I
can make out, that only works with BDB/MySQL. I even tried
the query directly using psql, but to no avail.


Andy.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-16 18:10

Message:
Logged In: YES 
user_id=176992

I wonder if this is a Hibernate problem. There was a new
Hibernate release on June 1st (2.1.4) - perhaps it is worth
giving that a spin to see if the Postgres problem got fixed ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

[Tm4j-developers] Future of Panckoucke 2

[Harald K. <har...@we...>]

Hi all,

to clearify my suggestion, what i wanted to suggest was the founding of a project which is somewhat like TMAPI. A Generic definition of interfaces (with a lightweight implementation of the Model interfaces - which is unlike TMAPI) and some example implementations. The TopicMap specific Implementations of this interfaces should (thats something Christoph and Jens perusaded me, i originall wanted to move the Abstractors as well)  either stay with the TMNav and panckoucke projects in TM4J or should merge into the TMNav project.

Cheers
Harald
_________________________________________________________
Mit WEB.DE FreePhone? mit hochster Qualitat ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201