RE: Topic Maps for Forrest ? (was RE: Proposal: alternative for book.xml)

[Kal Ahmed <ka...@techquila.com>]

At 17:41 25/03/2002 +0300, Piroumian, Konstantin wrote:
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > From: "Kal Ahmed" <ka...@techquila.com>
> > > At 14:42 23/03/2002 +0100, Stefano Mazzocchi wrote:
> > > >Jeff Turner wrote:
> > > >
><snip/>
> > > 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
>context-path).
>
>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!

Cheers,

Kal

XGump descriptor pretty-viewable in browser

[Nicola Ken Barozzi <ni...@apache.org>]

I found a cool side effect.

If you load the forrest.xgump descriptor in the browser from viewcvs, you
get a nice view because the stylesheets are there too to get.

See for yourself:

http://cvs.apache.org/viewcvs/~checkout~/xml-forrest/forrest.xgump

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------