forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kal Ahmed <>
Subject RE: Topic Maps for Forrest ? (was RE: Proposal: alternative for book.xml)
Date Tue, 26 Mar 2002 09:18:33 GMT
At 17:41 25/03/2002 +0300, Piroumian, Konstantin wrote:
> > From: Nicola Ken Barozzi []
> > From: "Kal Ahmed" <>
> > > At 14:42 23/03/2002 +0100, Stefano Mazzocchi wrote:
> > > >Jeff Turner wrote:
> > > >
> > > now), and I would love to be able to help out with any
> > Topic Map / RDF
> > > related work you may consider in the future. So consider
> > this as something
> > > of a pre-volunteering ;-)
> >
> > Good, pre-volunteering accepted :-)
> >
> > Since I personally don't have *any* /concrete/ clue on how to
> > implement this
> > in Forrest, I would be very happy to read a RT (random
> > thought, as we call
> > explanations-proposals) from you on this topic.
> > I'm very interested especially in real-life use cases and possible
> > implementations.
>I'd like to hear a brief explanation too.

I'll try and get something written this week then!

>One use-case of something like TM/RDF came to me while working on Cocoon
>i18n docs: there's a link from docs to javadocs (to the corresponding class)
>and the link looks like '../../org/apache/...', then I thought that it would
>be fine to have something like this: 'javadoc:/org/apache/...' instead and
>do not depend on the relative/absolute positions of docs and javadocs that
>change very quick. (Btw, this can be solved using a path like:
>'/$context-path$/javadoc/..., but document DTD does not define anything for
>Does TopicMaps solve such situations?

Not directly - although there are a number of modelling options. One of the 
easiest would be to model each class as a separate topic and then address 
the topic, rather than the javadoc. In either case (a javadoc: protocol URI 
or a Java class topic), you would end up having to resolve the address when 
you come to generate the HTML, but with a javadoc: URI you could *only* 
resolve to the Javadoc for the class. With a Java class topic, you could 
resolve to a topic that represents the class. The difference is that the 
topic can hold pointers to other documentation resources which describe the 
class as well as to the Javadoc. If you choose to model parts of your 
documentation as Topics or to extract the "relevant topics" from <index> 
tags for example, you could also generate links from the documentation out 
to the topics.

I'll try and address that in my random thinking!



View raw message