You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Piroumian, Konstantin" <KP...@flagship.ru> on 2002/03/25 15:41:28 UTC
RE: Topic Maps for Forrest ? (was RE: Proposal: alternative for
book.xml)
> 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.
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?
--
Konstantin Piroumian
kpiroumian@flagship.ru
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
XGump descriptor pretty-viewable in browser
Posted by 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)
---------------------------------------------------------------------
RE: Topic Maps for Forrest ? (was RE: Proposal: alternative
for book.xml)
Posted by 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