forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Link-Addressing, and breaking up the sitemap
Date Fri, 06 Sep 2002 16:29:46 GMT
On Fri, Sep 06, 2002 at 04:03:34PM +0200, Marc Portier wrote:
> >
> >Okay. What happens to the HTML that contained the link? We need to
> >rewrite the link to point to the 'location' attribute. As the link is
> >part of the contents, which is rendered by the sitemap, we need an XSLT
> >or something that rewrites links:
> >
> > <xsl:template match="link">
> >   <link>
> >     <xsl:attribute name="href">
> >       <xsl:if test="@href = 'doc'">
> >         <xsl:value-of select="./src/documentation/content/xdocs"/>
> >       </xsl:if>
> >       <xsl:if test="@href = 'mail'">
> >         <xsl:value-of select="..."/>
> >       </xsl:if>
> >       ...
> > </xsl:template>
> >
> > Suitably generalized, of course.
> mmm, the idea would be that you write your documents in such a 
> way that they use a common ref-prefix '/bar' for say docs 
> generated by foo...
> then you mention
> <part name="bar" location="./build/where-foo-dropped-it" />
> and tzadaam they get merged in

That's the goal..

> it is of course a bit naieve?
> in my first attempt at describing this I also thought about 
> reference-aliases for the case where you can say
> <part name="bar" location="./build/where-foo-dropped-it" >
>    <ref-alias name="old-bar" />
>    <ref-alias name="bar2" />
> </part>
> this would mean that there are still documents that would use the 
> old or alternative reference-prefix /old-bar resp /bar2 when they 
> should be using /bar

Don't see the need for extra prefixes. URIs are meant to uniquely
identify the resource.

> for those I think some tuned transformer could be created
> suggestions:
> - SAX filtering on anything that looks like a link-attribute?

Make LinkSerializer configurable?

> - having as config a small file that is generated from the 
> original one, (or is just the original one where it is 
> xpath-working out what it needs)
> still, a 2nd line kind of feature if you ask me
> >
> >Minor issue: if we're rewriting links, why bother copying the javadocs
> >inside the Cocoon context? We could just prepend '../javadocs', tell
> >Cocoon to ignore those links, and keep Javadocs outside. No need for Ant.
> >
> I feared that the javadoc example would lead to this....
> I was supposing that maybe one would want to e.g. start from 
> xml-javadocs ore something like that?

Then /xjdoc links get pointed to a different place than /jdoc.

Btw, how do you feel about a pseudo-protocol notation,
'javadoc:someClass'. Since we're going to need link rewriting anyway,
might as well not confuse users by suggesting that a real '/jdoc'
directory should exist.

> and there is other content to consider, no?

Link rewriting is useful all over the place. I've got links like: <link
href="elem:httpRequest">, which means "link to the section documenting
the httpRequest element". A stylesheet then replaces that with <link
href="httpRequest.html">. Alternatively, if producing a PDF, it gets
converted to a <fo:basic-link>.

Given a suitably smart link rewriter, and some support in the crawler,
and I think we can have links that are genuinely independent of the
output format and filesystem.

> >So if I'm not mistaken, the whole thing boils down to one link-rewriting
> >stylesheet.
> >
> >I'll try implementing it on my own project now.
> >
> let us know where it's leading you...

Javadoc links are working, eg: <link href="">
Pretty trivial to implement. With one stylesheet modification I can link
to either the online javadocs or locally produced javadocs.

I don't know how "deep" links would work though. Right now I've got an
xdoc like this:

    <section><title>Anteater tags</title>

And I'm trying to figure out how to link to the 'httpRequest' section
from another page. Probably an id attribute, which gets rendered in HTML
as <a nam=".."> would work.


View raw message