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

Re: [Tm4j-developers] =?ISO-8859-1?Q?TopicMapProvider=B4s?= addTopicMap

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

I think that this looks like a really good idea. I cannot really see any
downside to implementing this, so I'm +1 for doing it for the 0.9.0
release.

Cheers,

Kal

On Sat, 2003-10-25 at 09:45, Harald Kuhn wrote:
> Hi all,
> 
> while working on a TopicMapProviderFactory which uses TMHarvest for creating TMs (TopicMapConcept, the implementation is under org.tm4j.harvest.util in the TMHarvest Project) I realised, that the TopicMapProvider´s addTopicMap Method is somewhat restricted to serialized TopicMaps (from Streams).
> 
> To open up more possibilities for adding TMs from different sources I suggest the introduction of a new Interface TopicMapSource which abstractizes the Source of a TopicMap. This has a certain amount of impact on the api however. 
> 
> I also would like to store a reference to its Provider inside every TopicMap. The TopicMap is anyway inseperatable with its Provider and this could make a lot of "find the provider for this tm" obsolete. 
> 
> As i do not want to extend this email even longer, I created interfaces and implemented the outlines of all classes and interfaces affected by the changes.
> 
> The interfaces have the ending ..ext to show that they only contain the changes to the original interfaces, the classes have the ending ..fragment to show that they are only an outline.
> 
> I added them as topicmapsource.zip to the root directory of the tm4j project cvs.
> 
> Greetings 
> Harald
> ______________________________________________________________________________
> Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail
> und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] =?iso-8859-1?Q?TopicMapProvider=B4s=20addTopicMap?=

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

Hi all,

while working on a TopicMapProviderFactory which uses TMHarvest for creati=
ng TMs (TopicMapConcept, the implementation is under org.tm4j.harvest.util=
 in the TMHarvest Project) I realised, that the TopicMapProvider=B4s addTopi=
cMap Method is somewhat restricted to serialized TopicMaps (from Streams).=


To open up more possibilities for adding TMs from different sources I sugg=
est the introduction of a new Interface TopicMapSource which abstractizes =
the Source of a TopicMap. This has a certain amount of impact on the api h=
owever.=20

I also would like to store a reference to its Provider inside every TopicM=
ap. The TopicMap is anyway inseperatable with its Provider and this could =
make a lot of "find the provider for this tm" obsolete.=20

As i do not want to extend this email even longer, I created interfaces an=
d implemented the outlines of all classes and interfaces affected by the c=
hanges.

The interfaces have the ending ..ext to show that they only contain the ch=
anges to the original interfaces, the classes have the ending ..fragment t=
o show that they are only an outline.

I added them as topicmapsource.zip to the root directory of the tm4j proje=
ct cvs.

Greetings=20
Harald
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F
Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail
und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/=3Fmc=3D021182

Re: [Tm4j-developers] TopicMap baseLocator and resourceLocators

[Lars M. G. <la...@ga...>]

* Kal Ahmed
|
| That is a good point. Perhaps we should rename the property in the
| 0.9.0 release and deprecated resourceLocator.

I'd recommend doing that.

| [baseLocator] 
| 
| Yes, it would typically be the URI that you loaded the topic map
| from.  Though there is the interesting case of resolving URIs
| through a catalog file. Murray has added code for doing this to TM4J
| and I think that its a really powerful thing to be able to do (more
| levels of indirection is always a good thing). Presumably one should
| then use the URI prior to catalog resolution.

That's a tough choice, I think. I'd say it depends on which form of
the URIs you think people are likely to use to point to your topics,
and which URI you want relative locators to resolve against. The case
could be made either way depending on how you expect the feature to be
used. I don't know, so I can't really judge.
 
| And of course, merging an XTM file into an existing topic map is an
| entirely different ballgame. Though I guess that the XTM 1.1 spec
| considers that you parse the XTM file first then merge the SAM
| instances, right ? So as long as the "direct merge" has the same end
| result we are OK.

XTM 1.1 doesn't deal with that, so you can really define the result to
be whatever you please. I think your definition is what people are
likely to expect, and it's also the one the OKS implements.

| [xml:base]
| 
| Yeah, what you say is true, but given that XTM has this
| halfway-house hack that requires some xml:base processing and given
| also that (modulo external parsed entities), xml:base is a
| relatively trivial thing to extend throughout the document it seems
| daft to not at least cater for the case where someone reads the XML
| Base spec and decides to use it ;-)

All true, but doing so also means that you deviate from full
conformance. So some topic maps will give one result in TM4J and
another in other processors. In the next OKS version they will be
deemed invalid (by the validation code) and rejected. Users who are
unhappy with that can turn off validation and have the extra xml:base
attributes ignored.

But if you put in the option you mentioned you should be fine in the
sense that for those who want it there is a way to make TM4J
conformant.

| Thanks for your help Lars Marius!

Happy to help.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

Re: [Tm4j-developers] TopicMap baseLocator and resourceLocators

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

On Mon, 2003-10-13 at 23:59, Lars Marius Garshol wrote:
> * Kal Ahmed
> | 
> | Yes, SAM source locator == TM4J resourceLocator
> 
> Hmmmm. You don't worry that this will confuse people?
> "resourceLocator" is much more reminiscent of "resourceRef" than of
> "source locator", IMHO. People are probably quite confused about
> source locators already, and this may well make them give up on the
> concept altogether.
>  
That is a good point. Perhaps we should rename the property in the 0.9.0
release and deprecated resourceLocator.

> | No, resourceLocator (or source locator) - i.e. the id attribute is
> | expanded using the address of the XTM/LTM file as the base, because
> | resourceLocator is the address of the <topicMap> element, it follows
> | that you should resolve the ids of <topic> elements (and all the
> | other elements) relative to that, no ?
> 
> Yes, that works, *except* that for merged-in files you have to use the
> URI of that file instead. (And for entities you have to use the URI of
> the entity, maybe, or maybe not. This is one issue we never thrashed
> out. (Man, I *hate* hypertext.))
>  

Agreed (both on the merged-in files and the hating hypertext :)

> | Confusingly TM4J baseLocator != xml:base but is the URI assigned to
> | the topic map in the persistent store.
> | 
> | So now I'm not sure where that puts TM4J's baseLocator in relation
> | to the SAM baseLocator property. I just did a quick search through
> | the XTM 1.1 draft and found no occurrence of the string "base
> | locator" in it, so its not clear how that property is determined -
> | my feeling is that it is something relatively system specific and
> | that TM4J's way of doing it is to have it passed in as a parameter
> | when the TopicMap object is first created (whether that be by
> | parsing a file or just creating the object through the API).
> 
> It is kinda system specific, though for TMs loaded from XTM it will be
> the URI of the XTM document. The XTM 1.1 draft just hasn't been
> updated to reflect that after we added [base locator] back. If we
> don't do it that way you can't use baseLocator to resolve element IDs
> to absolute URIs.
> 

Yes, it would typically be the URI that you loaded the topic map from.
Though there is the interesting case of resolving URIs through a catalog
file. Murray has added code for doing this to TM4J and I think that its
a really powerful thing to be able to do (more levels of indirection is
always a good thing). Presumably one should then use the URI prior to
catalog resolution.

And of course, merging an XTM file into an existing topic map is an
entirely different ballgame. Though I guess that the XTM 1.1 spec
considers that you parse the XTM file first then merge the SAM
instances, right ? So as long as the "direct merge" has the same end
result we are OK.


> | [xml:base]
> | 
> | I think that OKS is right and ISO is wrong, but thanks for the
> | heads-up - there should probably be a "compatibility mode" option to
> | disable xml:base processing on elements other than topicMap then.
> 
> I used to think the same, but remember that xml:base is of limited
> utility anyway, and in an XTM document you can't define an xml:base at
> any level between that of the entire document and an individual
> <topic> or <association>, which makes it pretty much useless. 
> 
> IMHO nobody would have mourned if we ripped the whole thing out, which
> would be my inclination.
>  

Yeah, what you say is true, but given that XTM has this halfway-house
hack that requires some xml:base processing and given also that (modulo
external parsed entities), xml:base is a relatively trivial thing to
extend throughout the document it seems daft to not at least cater for
the case where someone reads the XML Base spec and decides to use it ;-)

> * Lars Marius Garshol
> |
> | (This was issue xtm-xmlbase-everywhere, BTW.)
>  
> * Kal Ahmed
> |
> | I must have been asleep ;-)
> 
> Or maybe you were awake then, and asleep now? :-)

I don't think so - my dreams are usually not topic map related :-)

>  
> | So perhaps I should (if we really want to save this information)
> | create a "contributingResources" property and put the address of
> | each contributing resource in there.
> 
> You could do that in TM4J, and I can tell you that you will find ways
> to use it. :) You will also still conform to TMDM, since you can add
> as much additional info as you want and still conform.

YAY! :)

Thanks for your help Lars Marius!

Cheers,

Kal
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] TopicMap baseLocator and resourceLocators

[Lars M. G. <la...@ga...>]

* Kal Ahmed
| 
| Yes, SAM source locator == TM4J resourceLocator

Hmmmm. You don't worry that this will confuse people?
"resourceLocator" is much more reminiscent of "resourceRef" than of
"source locator", IMHO. People are probably quite confused about
source locators already, and this may well make them give up on the
concept altogether.
 
| No, resourceLocator (or source locator) - i.e. the id attribute is
| expanded using the address of the XTM/LTM file as the base, because
| resourceLocator is the address of the <topicMap> element, it follows
| that you should resolve the ids of <topic> elements (and all the
| other elements) relative to that, no ?

Yes, that works, *except* that for merged-in files you have to use the
URI of that file instead. (And for entities you have to use the URI of
the entity, maybe, or maybe not. This is one issue we never thrashed
out. (Man, I *hate* hypertext.))
 
| Confusingly TM4J baseLocator != xml:base but is the URI assigned to
| the topic map in the persistent store.
| 
| So now I'm not sure where that puts TM4J's baseLocator in relation
| to the SAM baseLocator property. I just did a quick search through
| the XTM 1.1 draft and found no occurrence of the string "base
| locator" in it, so its not clear how that property is determined -
| my feeling is that it is something relatively system specific and
| that TM4J's way of doing it is to have it passed in as a parameter
| when the TopicMap object is first created (whether that be by
| parsing a file or just creating the object through the API).

It is kinda system specific, though for TMs loaded from XTM it will be
the URI of the XTM document. The XTM 1.1 draft just hasn't been
updated to reflect that after we added [base locator] back. If we
don't do it that way you can't use baseLocator to resolve element IDs
to absolute URIs.

| [xml:base]
| 
| I think that OKS is right and ISO is wrong, but thanks for the
| heads-up - there should probably be a "compatibility mode" option to
| disable xml:base processing on elements other than topicMap then.

I used to think the same, but remember that xml:base is of limited
utility anyway, and in an XTM document you can't define an xml:base at
any level between that of the entire document and an individual
<topic> or <association>, which makes it pretty much useless. 

IMHO nobody would have mourned if we ripped the whole thing out, which
would be my inclination.
 
* Lars Marius Garshol
|
| (This was issue xtm-xmlbase-everywhere, BTW.)
 
* Kal Ahmed
|
| I must have been asleep ;-)

Or maybe you were awake then, and asleep now? :-)
 
| So perhaps I should (if we really want to save this information)
| create a "contributingResources" property and put the address of
| each contributing resource in there.

You could do that in TM4J, and I can tell you that you will find ways
to use it. :) You will also still conform to TMDM, since you can add
as much additional info as you want and still conform.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

Re: [Tm4j-developers] TopicMap baseLocator and resourceLocators

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

On Mon, 2003-10-13 at 21:25, Lars Marius Garshol wrote:
> * Kal Ahmed
> | 
> | resourceLocators = the address of the topic map document(s) which
> | were parsed to create the TopicMap object. Because you can merge
> | together multiple XTM or LTM files, this property has to be a
> | Collection of Locator objects.
> 
> I guess you mean "source locator" here?
>  

Yes, SAM source locator == TM4J resourceLocator

> | Note, I believe that these two definitions match the proposed
> | Standard Application Model being developed by ISO for the next
> | version of the Topic Maps standard.
> 
> With the proviso above they do.

Good!

>  
> | When an XTM file is parsed, all id attribute values will be expanded
> | to full URLs by resolving them against the *resourceLocator*
> | parameter passed into the addTopicMap() method.
> 
> And here you meant "baseLocator" rather than "resourceLocator", right?
> 

No, resourceLocator (or source locator) - i.e. the id attribute is
expanded using the address of the XTM/LTM file as the base, because
resourceLocator is the address of the <topicMap> element, it follows
that you should resolve the ids of <topic> elements (and all the other
elements) relative to that, no ?

Confusingly TM4J baseLocator != xml:base but is the URI assigned to the
topic map in the persistent store. 

So now I'm not sure where that puts TM4J's baseLocator in relation to
the SAM baseLocator property. I just did a quick search through the XTM
1.1 draft and found no occurrence of the string "base locator" in it, so
its not clear how that property is determined - my feeling is that it is
something relatively system specific and that TM4J's way of doing it is
to have it passed in as a parameter when the TopicMap object is first
created (whether that be by parsing a file or just creating the object
through the API).

> | All references that are only fragment identifiers (i.e start with a
> | #) will be resolved against the *resourceLocator* parameter. All
> | references that are relative URIs will be resolved against the
> | *baseLocator* identifier, OR the value of the xml:base attribute on
> | the element being processed or its closest ancestor element (in line
> | with XML Base recommendataion).
> 
> Note that XML 1.0 only supports -xml:base- on <topicMap/>, according
> to the DTD. The OKS supports it everywhere, but ISO has resolved that
> XTM 1.1 will enforce the DTD rule from 1.0. This just FYI.
> 

I think that OKS is right and ISO is wrong, but thanks for the heads-up
- there should probably be a "compatibility mode" option to disable
xml:base processing on elements other than topicMap then.

> (This was issue xtm-xmlbase-everywhere, BTW.)

I must have been asleep ;-)

>  
> | When a topic map is exported, all references within the topic map
> | will be written out using fragment identifiers. All references
> | outside the topic map which can be expressed relative to the
> | *baseLocator* property will be written as relative URIs, and the
> | xml:base attribute of the topicMap element will be set to the
> | baseLocator address. All references outside the topic map which
> | cannot be expressed relative to the baseLocator property will be
> | exported as full URIs.
> 
> I assume you mean "all <resourceRef/> and <subjectIndicatorRef/>
> references" here, since if you do this to <topicRef/>s many exports
> are likely to fail to reimport with a nasty grinding sound. :)

Oh yes indeed :)

>  
> | When a topic map is added to a TopicMapProvider and merged with an
> | existing topic map, the resourceLocator parameter value will be
> | added to the resourceLocators of the existing TopicMap. 
> 
> This you mustn't do. It effectively means that you assert that the two
> topic maps are the same topic map, which is not the case. (If they
> were there would be no need to merge them.) 
> 
> See <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=merge-prop-srclocs >.
> 

Ah, ok - I can see why this decision was made. My thought was that we
would be retaining the addresses of all resources (XTM or LTM) which
contributed to the TopicMap, not that we would be asserting anything
about the identity of the TopicMap. So perhaps I should (if we really
want to save this information) create a "contributingResources" property
and put the address of each contributing resource in there.

> The current XTM 1.1 draft should be up to date with this and thus
> carefully *not* say that this should be done. :-)

So it doesn't :)

Cheers,

Kal

-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] TopicMap baseLocator and resourceLocators

[Lars M. G. <la...@ga...>]

* Kal Ahmed
| 
| resourceLocators = the address of the topic map document(s) which
| were parsed to create the TopicMap object. Because you can merge
| together multiple XTM or LTM files, this property has to be a
| Collection of Locator objects.

I guess you mean "source locator" here?
 
| Note, I believe that these two definitions match the proposed
| Standard Application Model being developed by ISO for the next
| version of the Topic Maps standard.

With the proviso above they do.
 
| When an XTM file is parsed, all id attribute values will be expanded
| to full URLs by resolving them against the *resourceLocator*
| parameter passed into the addTopicMap() method.

And here you meant "baseLocator" rather than "resourceLocator", right?

| All references that are only fragment identifiers (i.e start with a
| #) will be resolved against the *resourceLocator* parameter. All
| references that are relative URIs will be resolved against the
| *baseLocator* identifier, OR the value of the xml:base attribute on
| the element being processed or its closest ancestor element (in line
| with XML Base recommendataion).

Note that XML 1.0 only supports -xml:base- on <topicMap/>, according
to the DTD. The OKS supports it everywhere, but ISO has resolved that
XTM 1.1 will enforce the DTD rule from 1.0. This just FYI.

(This was issue xtm-xmlbase-everywhere, BTW.)
 
| When a topic map is exported, all references within the topic map
| will be written out using fragment identifiers. All references
| outside the topic map which can be expressed relative to the
| *baseLocator* property will be written as relative URIs, and the
| xml:base attribute of the topicMap element will be set to the
| baseLocator address. All references outside the topic map which
| cannot be expressed relative to the baseLocator property will be
| exported as full URIs.

I assume you mean "all <resourceRef/> and <subjectIndicatorRef/>
references" here, since if you do this to <topicRef/>s many exports
are likely to fail to reimport with a nasty grinding sound. :)
 
| When a topic map is added to a TopicMapProvider and merged with an
| existing topic map, the resourceLocator parameter value will be
| added to the resourceLocators of the existing TopicMap. 

This you mustn't do. It effectively means that you assert that the two
topic maps are the same topic map, which is not the case. (If they
were there would be no need to merge them.) 

See <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=merge-prop-srclocs >.

The current XTM 1.1 draft should be up to date with this and thus
carefully *not* say that this should be done. :-)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

[Tm4j-developers] TopicMap baseLocator and resourceLocators

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

Hi all,

I've been reviewing the way that TopicMap baseLocator and
resourceLocators properties are used by the current (CVS HEAD) codebase
and I think that there is a need for a bit of a cleanup. This email
outlines what I propose to do - any comments would be very welcome!

In the current codebase, baseLocator and resourceLocators are not
cleanly separated. I plan to make the separation much cleaner as
follows:

baseLocator = the address of the topic map resource as a whole. This
address is a unique key for the topic map in the TopicMapProvider's data
store (so there will still be TopicMapProvider.getTopicMap(Locator
baseLocator)). The baseLocator of a topic map can be changed at any time
as long as the address chosen is still unique in the TopicMapProvider.

resourceLocators = the address of the topic map document(s) which were
parsed to create the TopicMap object. Because you can merge together
multiple XTM or LTM files, this property has to be a Collection of
Locator objects. 

Note, I believe that these two definitions match the proposed Standard
Application Model being developed by ISO for the next version of the
Topic Maps standard.

For the API, the TopicMapProvider interface currently has addTopicMap
methods that each take a single locator. This locator will be used as
the default baseLocator for the topic map and the first resourceLocator
for the topic map. New methods will be added that allow the baseLocator
and resourceLocator to be set to different values too. 

When an XTM file is parsed, all id attribute values will be expanded to
full URLs by resolving them against the *resourceLocator* parameter
passed into the addTopicMap() method. All references that are only
fragment identifiers (i.e start with a #) will be resolved against the
*resourceLocator* parameter. All references that are relative URIs will
be resolved against the *baseLocator* identifier, OR the value of the
xml:base attribute on the element being processed or its closest
ancestor element (in line with XML Base recommendataion).

LTM files will be parsed with similar rules, except that an LTM file can
only have a single BASEURI directive (which will be treated as an
xml:base on the root element of an XTM file).

When a topic map is exported, all references within the topic map will
be written out using fragment identifiers. All references outside the
topic map which can be expressed relative to the *baseLocator* property
will be written as relative URIs, and the xml:base attribute of the
topicMap element will be set to the baseLocator address. All references
outside the topic map which cannot be expressed relative to the
baseLocator property will be exported as full URIs.

When a topic map is added to a TopicMapProvider and merged with an
existing topic map, the resourceLocator parameter value will be added to
the resourceLocators of the existing TopicMap. The baseLocator parameter
value will be treated as if it were the xml:base attribute value of the
topicMap element of the document.

Note: When using TopicMap.getObjectByResourceLocator(), it will be
important for a programmer to be aware of how id attribute values are
expanded into full URIs (although that is no different to the case now).

Hopefully I have covered all the main operations that involve these
properties in the current API. I plan to implement this in CVS HEAD, but
not in the 0.8.x branch unless there is great demand for that.

Thanks for reading this far. If you have comments on this proposal,
please let me know!

Cheers,

Kal

-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] EclipseProjectTask: An Ant task for generating Eclipse project files

[Florian G. H. <f.g...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello guys,

with all the different TM4J subprojects emerging and just about everyone=20
starting to use Eclipse, I thought an Ant task which generates Eclipse=20
=2Eproject and .classpath files may be helpful. So here's one:=20
org.tm4j.ant.taskdefs.EclipseProjectTask.

What it does is easily explained: it generates Eclipse .project and .classp=
ath=20
files so you can start working with Eclipse immediately after a CVS checkou=
t=20
and an Ant run. No need to set up source or output directories or the Eclip=
se=20
classpath from Eclipse itself.=20

I have made some changes to the TM4J build.xml to accommodate the new task =
and=20
to include a new "eclipse" target that runs it. As long as the task hasn't=
=20
seen some more extensive testing, it does not overwrite your existing=20
=2Eproject and .classpath files. Instead, it generates project.test and=20
classpath.test so as not to break anything.

I have so far tested the task for the TM4J and kamal modules, and will go=20
through the other TM4J subprojects piece by piece in the next few days.=20
However, I don't have a Windows box at my disposal, and I also don't have=20
access to any JDK 1.2 installation. So if one of you guys is inclined (and=
=20
has the time) to test this on other platforms than I did, please do and=20
holler if things break.

As long as there isn't any more formal documentation, please run "ant=20
full-doc" and check the Javadocs for a description of supported attributes=
=20
and nested elements.

Happy testing!
=46lorian

P.S.: And yes I've run the code through Jalopy. :-)

=2D --=20
=46lorian G. Haas <f.g...@gm...> http://member.ycn.com/~fgh/en/

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/gW3egW2VC0bQC+MRAtKJAJ9uVBTtHRmyYFtbxuytUHRicT/QsQCfQQ1x
mY7RBd6VYeF+X64eLghq0/8=3D
=3DlIuY
=2D----END PGP SIGNATURE-----

Re: [Tm4j-developers] Recent commits to tm4web/cocoon

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

Hi Florian,

I haven't had chance to take a peek at the code yet, but the output
looks good! Like the other Cocoon variant, there is the problem of
association naming, but I think that there are a couple of ways to solve
this.

It would be good to integrate the approaches (if they are wildly
different) into a single approach to TM4J/Cocoon integration, and ideas
for new Cocoon transformers would be welcome. I guess that we should
first try and sketch out an overall architecture though. There are
things we should consider such as the inclusion of the Panckoucke
abstraction tools into the rendering pipeline (perhaps as an optional
step), and the use of Harald's JNDI provider.

If you get chance to sketch out your ideas for transformers, maybe we
can make a start on creating a simple architecture diagram to guide the
future development. When I get some time, I plan to do the same for the
Velocity and Velocity/Struts integrations too.

Cheers,

Kal


On Sun, 2003-09-14 at 17:57, Florian G. Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello guys,
> 
> as you may have noticed, I've recently committed some files to the tm4web 
> module. This is the Cocoon integration stuff I've wanted to complete for a 
> long time. Note that this is not yet integrated with Kal's earlier work on 
> that matter, I've postponed this for now and included and alternate build 
> file which I suggest we'll eventually merge. Hope you're not too p***ed off 
> about that, Kal.
> 
> REAL QUICK GETTING STARTED GUIDE:
> * Install Cocoon, preferably 2.1 and above if you want to use offline site 
> generation.
> * Install Ant if you haven't yet, which I guess is unlikely. :-)
> * Change to the "cocoon" subdirectory in your tm4web CVS checkout folder.
> * Open build.properties and set the path to your Cocoon webapp.
> * Run "ant -f alternate-build.xml -projecthelp" to get an idea what it's all 
> about.
> * Run "ant build-site" to get a basic site structure in build/site.
> * Drop one or more XTM files into build/site/src. If you use Kal's MP3 topic 
> map, then the sample settings in build.properties should work for you.
> * Then either:
>   - Run "ant deploy-site" to deploy the structure in build/site to the 
> location of your choosing. The sitemap.xmap included in build/site can be 
> used either as a subsitemap, or as a replacement for the default Cocoon 
> sitemap.
>   or:
>   - Run "ant build-offline" to get an offline-generated web site structure in 
> build/offline. For this to work, set a proper starting point in 
> build.properties.
> * And you're done.
> 
> Whether you choose to deploy your site into your Cocoon structure or whether 
> you opt for offline generation, the same rule always applies: the site 
> contains a "virtual directory" for each of your XTM sources, where each topic 
> becomes a "virtual file" whose filename is the topic ID. So, sticking with 
> the example from Kal's MP3 topic map, the topic "performer-primus" would be 
> at /path/to/output/dir/mp3/performer-primus.html or 
> http://cocoonhost/path/to/subsitemap/mp3/performer-primus.html. You get the 
> idea. So you can either retrieve the output structure from your local Cocoon 
> installation or from disk, depending on which build option you chose.
> 
> You should also take a look at build/site/README if time permits.
> 
> If you want to take a quick look at what this produces without going through 
> the setup yourself, I invite you to take a peek at 
> http://member.ycn.com/~fgh/en/.
> 
> Now, needless to say, anyone who has the time and inclination to test this, 
> please do and be aware that I'd be more than happy about your feedback. I 
> realize that there is still a bunch of work to do -- as for now, this is just 
> an XTM publishing framework without much of the advanced capabilities of TM4J 
> at all. 
> 
> Kal, please instruct me as to how to go on merging this with your earlier work 
> on Cocoon integration. I have some ideas about Cocoon transformers that might 
> complement this.
> 
> I'd like to write a bit more about this whole issue right now, but I'm a bit 
> in a hurry tonight and I gotta run. Please bear with me! :-)
> 
> Looking forward to hearing from some of you guys soon,
> Cheers,
> Florian
> 
> - -- 
> Florian G. Haas <f.g...@gm...>
> 
> GnuPG key ID: 0x46D00BE3
> Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3
> 
> My GnuPG key is available from the public PGP key server at
> pgp.mit.edu (and various other key servers).
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> 
> iD8DBQE/ZJ4RgW2VC0bQC+MRAm6NAKC4x12eZcFlp+abiSOoFNDZxQsQXQCeLTx0
> l5yBVQNfduJusBNdS7jfu0A=
> =J7NQ
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] [correction] Recent commits to tm4web/cocoon

[Florian G. H. <f.g...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

Ahem, a few typos...=20

| * Run "ant build-site" to get a basic site structure in build/site.

This should of course be "ant -f alternate-build.xml build-site".

|   - Run "ant deploy-site" to deploy the structure in build/site to the

Same here. "ant -f alternate-build.xml deploy-site" is correct.

|   - Run "ant build-offline" to get an offline-generated web site structure

And once again, read "ant -f alternate-build.xml build-offline".

Sorry if I've confused anybody.
=46lorian

=2D --=20
=46lorian G. Haas <f.g...@gm...>

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/ZJ9qgW2VC0bQC+MRAg0aAKCInwMi/ZrEiPfAM07Q4w76e5T0LQCcDa1p
eXR9y0a/Rt9BhJUdXUgG3x0=3D
=3Dn9xB
=2D----END PGP SIGNATURE-----

[Tm4j-developers] Recent commits to tm4web/cocoon

[Florian G. H. <f.g...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello guys,

as you may have noticed, I've recently committed some files to the tm4web=20
module. This is the Cocoon integration stuff I've wanted to complete for a=
=20
long time. Note that this is not yet integrated with Kal's earlier work on=
=20
that matter, I've postponed this for now and included and alternate build=20
file which I suggest we'll eventually merge. Hope you're not too p***ed off=
=20
about that, Kal.

REAL QUICK GETTING STARTED GUIDE:
* Install Cocoon, preferably 2.1 and above if you want to use offline site=
=20
generation.
* Install Ant if you haven't yet, which I guess is unlikely. :-)
* Change to the "cocoon" subdirectory in your tm4web CVS checkout folder.
* Open build.properties and set the path to your Cocoon webapp.
* Run "ant -f alternate-build.xml -projecthelp" to get an idea what it's al=
l=20
about.
* Run "ant build-site" to get a basic site structure in build/site.
* Drop one or more XTM files into build/site/src. If you use Kal's MP3 topi=
c=20
map, then the sample settings in build.properties should work for you.
* Then either:
  - Run "ant deploy-site" to deploy the structure in build/site to the=20
location of your choosing. The sitemap.xmap included in build/site can be=20
used either as a subsitemap, or as a replacement for the default Cocoon=20
sitemap.
  or:
  - Run "ant build-offline" to get an offline-generated web site structure =
in=20
build/offline. For this to work, set a proper starting point in=20
build.properties.
* And you're done.

Whether you choose to deploy your site into your Cocoon structure or whethe=
r=20
you opt for offline generation, the same rule always applies: the site=20
contains a "virtual directory" for each of your XTM sources, where each top=
ic=20
becomes a "virtual file" whose filename is the topic ID. So, sticking with=
=20
the example from Kal's MP3 topic map, the topic "performer-primus" would be=
=20
at /path/to/output/dir/mp3/performer-primus.html or=20
http://cocoonhost/path/to/subsitemap/mp3/performer-primus.html. You get the=
=20
idea. So you can either retrieve the output structure from your local Cocoo=
n=20
installation or from disk, depending on which build option you chose.

You should also take a look at build/site/README if time permits.

If you want to take a quick look at what this produces without going throug=
h=20
the setup yourself, I invite you to take a peek at=20
http://member.ycn.com/~fgh/en/.

Now, needless to say, anyone who has the time and inclination to test this,=
=20
please do and be aware that I'd be more than happy about your feedback. I=20
realize that there is still a bunch of work to do -- as for now, this is ju=
st=20
an XTM publishing framework without much of the advanced capabilities of TM=
4J=20
at all.=20

Kal, please instruct me as to how to go on merging this with your earlier w=
ork=20
on Cocoon integration. I have some ideas about Cocoon transformers that mig=
ht=20
complement this.

I'd like to write a bit more about this whole issue right now, but I'm a bi=
t=20
in a hurry tonight and I gotta run. Please bear with me! :-)

Looking forward to hearing from some of you guys soon,
Cheers,
=46lorian

=2D --=20
=46lorian G. Haas <f.g...@gm...>

GnuPG key ID: 0x46D00BE3
Key fingerprint: 18B4 3E7B 191E F534 254A  1F7C 816D 950B 46D0 0BE3

My GnuPG key is available from the public PGP key server at
pgp.mit.edu (and various other key servers).

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/ZJ4RgW2VC0bQC+MRAm6NAKC4x12eZcFlp+abiSOoFNDZxQsQXQCeLTx0
l5yBVQNfduJusBNdS7jfu0A=3D
=3DJ7NQ
=2D----END PGP SIGNATURE-----

Re: [Tm4j-developers] Source code styles

[Martin S. <hu...@we...>]

Christoph Froehlich wrote:
> Am Fre, 2003-08-29 um 12.37 schrieb Lars Marius Garshol:
> 
>>* Gerd Mueller
>>| 
>>| +1 for Sun conventions.
>>|
>>| [...position of variable declarations...]
>>| 
>>| I agree with this point. 
>>|
>>| [...]
>>| 
>>| I prefer the Sun version, i.e. opening brace at the end of line,
>>| since in my eyes it generates a more compact code.
>>
>>FWIW, I agree 100% with everything Gerd wrote.
> 
> 
> me too

and mee too :-))

Martin

> 
> 
> Christoph

Re: [Tm4j-developers] Source code styles

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

On Fri, 2003-08-29 at 10:13, Elmar Seestaedt wrote:
> Hi Kal and Hi the rest of you,
> 
> though I don´t have strong opposition to Sun conventions I have some
> arguments against them:
> 
> <snip>
> Put declarations only at the beginning of blocks. (A block is any code
> surrounded by curly braces "{" and "}".) Don't wait to declare variables until
> their first use; it can confuse the unwary programmer and hamper code
> portability within the scope. 
> <snap>
> I learned and I prefer to wait with declaration because having all variables
> very early leds the developer to "double use" of variables, which we
> probably all agree, should be avoided.

I agree with you on this point.

> <snip comment="same applies to class and interface definition">
> The opening brace should be at the end of the line that begins the compound
> statement; the closing brace should begin a line and be indented to the
> beginning of the compound statement. 
> <snap comment="hmm actually this snipsnap stuff is not well formed ;-)">
> I actually strongly prefer putting each curly brace on a seperate line, left
> aligned with the compund statement and aligned with the corresponding
> closing brace. I really think that this improves readability a lot.
> 
Me too - but I think that we are in the minority on this...

> I agree with you that Jalopy rocks, and I think there is an Jalopy ANT task.
> Probably we should introduce an ant task that formats the code according to
> a user specified coding style. Furthermore check in the jalopy style that we
> will use into CVS and have another ANT task that beautifies the code to the
> commonly agreed style before code is checked into CVS. I´m not sure if this
> has side effects ..

Well, if Jalopy works properly, then there should be no side effects in
terms of compilation or runtime behaviour. However I have noticed that
Jalopy falls over on one particularly messed up file
(org/tm4j/topicmap/memory/TopicMapFactoryImpl.java which appears to have
*multiple* 0x0D characters at the ends of lines!), and as a result would
either not modify the file at all (the default behaviour) or else loose
the CVS log comments at the end of the file (if you force it to continue
after encountering an error).

I like the idea of having a "pre-checkin" formatting task and a
"personal style" formatting task. It should be the responsibility of the
developer to ensure that their chosen personal style does not cause
side-effects and also to ensure that they reformat to the standard style
before check in.

Having typed that, I just *know* I'll be the first to break that rule :)

I added a build file called code-formatting.xml to CVS last night. I
wanted to keep this separate from the main build.xml file as the Jalopy
taskdef requires that you have Jalopy installed and I didn't want to add
yet another tool dependency to the basic TM4J build requirements. The
current version of code-formatting.xml does the builtin (Sun-style)
formatting, and also uses the FixCRLF Task to force line-endings and eof
markers to Unix format.

BTW, there is a Jalopy plugin for Eclipse. Perhaps that would make life
easier for those of us who prefer a different style for development ?


Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531

Re: Re: [Tm4j-developers] Source code styles

[niko <ni...@na...>]

I agree with this style also :)
.. and yes, jalopy does a very good job, even in embedding it automagically into the ant process.

-- Niko

* Gerd Mueller
| 
| +1 for Sun conventions.
|
| [...position of variable declarations...]
| 
| I agree with this point. 
|
| [...]
| 
| I prefer the Sun version, i.e. opening brace at the end of line,
| since in my eyes it generates a more compact code.

* Lars Marius
| FWIW, I agree 100% with everything Gerd wrote.

Re: [Tm4j-developers] Source code styles

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

Am Fre, 2003-08-29 um 12.37 schrieb Lars Marius Garshol:
> * Gerd Mueller
> | 
> | +1 for Sun conventions.
> |
> | [...position of variable declarations...]
> | 
> | I agree with this point. 
> |
> | [...]
> | 
> | I prefer the Sun version, i.e. opening brace at the end of line,
> | since in my eyes it generates a more compact code.
> 
> FWIW, I agree 100% with everything Gerd wrote.

me too


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

Re: [Tm4j-developers] Source code styles

[Lars M. G. <la...@ga...>]

* Gerd Mueller
| 
| +1 for Sun conventions.
|
| [...position of variable declarations...]
| 
| I agree with this point. 
|
| [...]
| 
| I prefer the Sun version, i.e. opening brace at the end of line,
| since in my eyes it generates a more compact code.

FWIW, I agree 100% with everything Gerd wrote.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >

Re: [Tm4j-developers] Source code styles

[Gerd M. <Ger...@sm...>]

Hi,

+1 for Sun conventions.

> though I don´t have strong opposition to Sun conventions I have some
> arguments against them:
> 
> <snip>
> Put declarations only at the beginning of blocks. (A block is any code
> surrounded by curly braces "{" and "}".) Don't wait to declare variables until
> their first use; it can confuse the unwary programmer and hamper code
> portability within the scope. 
> <snap>
> I learned and I prefer to wait with declaration because having all variables
> very early leds the developer to "double use" of variables, which we
> probably all agree, should be avoided.

I agree with this point. 
 
> <snip comment="same applies to class and interface definition">
> The opening brace should be at the end of the line that begins the compound
> statement; the closing brace should begin a line and be indented to the
> beginning of the compound statement. 
> <snap comment="hmm actually this snipsnap stuff is not well formed ;-)">
> I actually strongly prefer putting each curly brace on a seperate line, left
> aligned with the compund statement and aligned with the corresponding
> closing brace. I really think that this improves readability a lot.

I prefer the Sun version, i.e. opening brace at the end of line, since in my
eyes it generates a more compact code. 
 
Best Regards,
gerd

________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

Re: [Tm4j-developers] Source code styles

[Elmar S. <eso...@gm...>]

Hi Kal and Hi the rest of you,

though I don´t have strong opposition to Sun conventions I have some
arguments against them:

<snip>
Put declarations only at the beginning of blocks. (A block is any code
surrounded by curly braces "{" and "}".) Don't wait to declare variables until
their first use; it can confuse the unwary programmer and hamper code
portability within the scope. 
<snap>
I learned and I prefer to wait with declaration because having all variables
very early leds the developer to "double use" of variables, which we
probably all agree, should be avoided.

<snip comment="same applies to class and interface definition">
The opening brace should be at the end of the line that begins the compound
statement; the closing brace should begin a line and be indented to the
beginning of the compound statement. 
<snap comment="hmm actually this snipsnap stuff is not well formed ;-)">
I actually strongly prefer putting each curly brace on a seperate line, left
aligned with the compund statement and aligned with the corresponding
closing brace. I really think that this improves readability a lot.

I agree with you that Jalopy rocks, and I think there is an Jalopy ANT task.
Probably we should introduce an ant task that formats the code according to
a user specified coding style. Furthermore check in the jalopy style that we
will use into CVS and have another ANT task that beautifies the code to the
commonly agreed style before code is checked into CVS. I´m not sure if this
has side effects ..


Cheers Elmar


> Hi all,
> 
> I've spent a bit of time recently going through the core TM4J codebase
> and eliminating a lot of obsoleted code and old deprecated methods. My
> plan is that 0.9.0 will be released with all methods deprecated in 0.8.2
> or before removed. The only deprecated methods left would be those
> actually deprecated in the 0.9.0 release (there may be one or two these)
> - except for the Scope changes which have required a number of methods
> to be simply removed from the interfaces and implementations entirely.
> 
> Anyway, the point of telling you all this is that in going through the
> code, I have noticed how badly formatted it has got - mostly my fault :)
> also alot of problems caused by the fact that I often switch development
> between my Windows laptop and my Linux home machine, with all the
> line-ending-differences a slight-differences-in-eclipse-setups that this
> involves.
> 
> So I have played with Jalopy (http://jalopy.sourceforge.net) which does
> a pretty nice job of reformatting the code to whatever style we decide
> on.
> 
> And thats the problem.
> 
> What coding style do people prefer ? I see many people (other than
> myself...) using the Sun style guidelines. I have a more C style (not
> quite K+R...actually fairly strongly influenced by my time in Xerox),
> but I am happy to change that for the sake of consistency and
> readability.
> 
> My instinct is to go with Sun style guidelines unless there is strong
> opposition from this group.
> 
> So if you have any concerns or suggestions, please raise them now.
> Although I will probably check the prettified code in today, we can
> always reformat it again with Jalopy (Jalopy Rocks!)
> 
> Cheers,
> 
> Kal
> -- 
> Kal Ahmed, Techquila
> Standards-based Information Management
> e: ka...@te...
> w: www.techquila.com
> p: +44 7968 529531
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
> 

[Tm4j-developers] Source code styles

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

Hi all,

I've spent a bit of time recently going through the core TM4J codebase
and eliminating a lot of obsoleted code and old deprecated methods. My
plan is that 0.9.0 will be released with all methods deprecated in 0.8.2
or before removed. The only deprecated methods left would be those
actually deprecated in the 0.9.0 release (there may be one or two these)
- except for the Scope changes which have required a number of methods
to be simply removed from the interfaces and implementations entirely.

Anyway, the point of telling you all this is that in going through the
code, I have noticed how badly formatted it has got - mostly my fault :)
also alot of problems caused by the fact that I often switch development
between my Windows laptop and my Linux home machine, with all the
line-ending-differences a slight-differences-in-eclipse-setups that this
involves.

So I have played with Jalopy (http://jalopy.sourceforge.net) which does
a pretty nice job of reformatting the code to whatever style we decide
on.

And thats the problem.

What coding style do people prefer ? I see many people (other than
myself...) using the Sun style guidelines. I have a more C style (not
quite K+R...actually fairly strongly influenced by my time in Xerox),
but I am happy to change that for the sake of consistency and
readability.

My instinct is to go with Sun style guidelines unless there is strong
opposition from this group.

So if you have any concerns or suggestions, please raise them now.
Although I will probably check the prettified code in today, we can
always reformat it again with Jalopy (Jalopy Rocks!)

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531

Re: [Tm4j-developers] Hibernate backend update

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

Hi Markus

I have just checked in a whole bunch of changes to the HEAD branch in
CVS, including an upgrade to hibernate 2. (2.0.1)

I have also had a first go at improving the transaction control in
hibernate. I am guessing that that might be the first stop in improving
import performance although I haven't yet decided how to propagate the
changes so that the XTMBuilder can make use of longer transactions to
improve performance.

The other performance boost that I plan to implement is to allow the
dynamic merging model of TM4J to be turned off. The dynamic merging
model allows topics that get merged to be "unmerged" without losing
their original information. This is a powerful feature for some
applications, but it involves a high overhead when topics are inserted
or modified. Especially in the Hibernate back-end where it can require
several database queries to do a full transitive closure of the
dynamically merged topics. So by allowing a more "traditional" static
merge model where topics get smushed together and cannot be unmerged
again, I think that performance can be significantly improved. This
change is high priority for me, meaning I intend to implement it for the
0.9.0 release.

If you have other suggestions for improving import performance, then I
would be happy to discuss that with you as performance metrics and
performance enhancements are going to be high priority for the 0.9.0 ->
1.0 development track.

Cheers,

Kal

On Tue, 2003-07-15 at 11:21, keil wrote:
> Hi!
> 
> I'd like to update the hibernate backend to hibernate 2 and to write a 
> faster importer for huge topic maps. To whom can I post the updated 
> source when it is finished?
> 
> Greetings
> Markus
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] Tm4j-developers -- confirmation of subscription -- request 685161

[<ro...@gm...>]

[Tm4j-developers] Hibernate backend update

[keil <ke...@gm...>]

Hi!

I'd like to update the hibernate backend to hibernate 2 and to write a 
faster importer for huge topic maps. To whom can I post the updated 
source when it is finished?

Greetings
Markus

[Tm4j-developers] WARNING: Major change to TM4J Interfaces

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

Hi all,

I am just about to check a major change to the TM4J interfaces into CVS.
This change completely removes the Scope interface and its
implementations as we discussed (a while ago now) on this list.

This means that:
a) Almost all code that is based on 0.8.x will probably need rewriting
b) The persistent back-ends are not compatible with 0.8.x back-ends

Please be aware of this if you use a CVS snapshot for your development
work.

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531

[Tm4j-developers] TM4Web-VTL developement

[Asle P. <asl...@in...>]

I am running an experiment using TM4Web-VTL. I am using the .vm templates=
 from=20
the tm4j/resource/templates/sitemap directory. If the current Topic is an=
=20
assoc-type nothing seem to be listed in the navigation bar. (look at=20
http://www.techquila.com/topicmaps/tmworld/11538.html) I would like to se=
e=20
all players of all roles which has the current topic as their assoc-type.=
=20
Topicdetail.vm and associations.vm seem to be an appopriate place to do t=
his.=20
Which functions/filters/testers/iterators should I consider to implement =
this=20
feature?

BTW! I think there is an error in the userdoc.xml (I had to remove a <par=
a>=20
tag in order to compile it).

regards,
Asle