forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [RT] Linking revisited: A general linking system
Date Mon, 14 Oct 2002 05:48:11 GMT
On Mon, Oct 14, 2002 at 12:25:53AM +0200, Bernhard Huber wrote:
> Hi,
> Robert Koberg pointed me to your posting about linkmaps,
> as i have made some posting about "sitemap design - model and process" 
> in the cocoon-dev list,

I read that with interest.  Any way of making the sitemap more
comprehensible would be useful in Forrest.

> Some implementation hints:
> I think Cocoon already defines a lot of classes which you might
> need for implementing your ideas.
> org.apache.cocoon.components.source.impl.CocoonSourceFactory, and 
> org.apache.cocoon.components.source.SitemapSource implements the 'cocoon:' 
> protocol.

Yes, I've taken a brief look at excalibur's sourceresolve package. I'm
still not sure how a pseudo-protocol like site: could be implemented.

> org.apache.cocoon.components.source.URLRewriter allows some kind of URL 
> rewriting for the cocoon protocol.
> URLRewriter is already the 'linkresolver.xsl' transformer step.

I don't fully understand it, but it does look useful for Forrest in two
 - As you say, rewriting site: urls
 - Doing token replacement in XML content. Eg, Forrest skin files (eg
   breadcrumbs.js) currently contain Ant @tokens@, which are replaced
   with values when copied from src/documentation/* to build/tmp/*. If
   Cocoon could replace these tokens with a FilterTransformer, we could
   eliminate the copy step.

> Checking the implementation of 'cocoon:' might help in your 'site:' 
> implementation.
> Next, the view 'links' in the forrest sitmap, generates some sort of a link 
> map.

Hm yes.. that could be better than traversing the directories to create a
dynamic linkmap.

> Moreover there are LinkStatusGenerator, and AugmentTransformer already in 
> the source which do similar things.
> Some questions:
> How does the libre concept of forrest fit into your linkmap concept?

It fits in very nicely. Here is the intended output from Libre:

<?xml version="1.0" encoding="UTF-8"?>
<collection xmlns="">
  <collection label="content">
    <collection label="xdocs">
      <item label="dreams.xml" 
               title="Forrest dream list"/>
      <item label="faq.xml" 
      <item label="book.xml" 
      <item label="contrib.xml" 
               title="Contribution to Forrest"/>
      <item label="mail-archives.xml" 
               title="Mail Archives"/>
      <item label="mail-lists.xml" 
               title="Mailing Lists"/>
      <item label="license.xml" 
               title="The Apache Software License"/>
      <item label="index.xml" 
               title="Welcome to Forrest"/>
      <item label="who.xml" 
               title="Who we are"/>

That is very similar to a linkmap. So when it comes to implementing dynamically
generated linkmaps (see section 4 of the RT), Libre would be the tool to use.

> You once noted that the sitemap becomes completly independent from 
> the filesystem, and it is possible to move all documents into Xindice
> without changing the sitemap, where do I specify the the documents
> should be read from xindice, and not from the filesystem.

In the linkmap file, which is the mapping from "site" urls to "http", "file",
"xmldb" and all the other types.

> Moreover should it be possible to mix xindice, and filesystem access?

Yes, the linkmap is just a "directory" of URIs. By specifying
"site:/site/index", you're saying "give me the URL for the
'site/index' node". Here's an example linkmap:

<site uri="file:./content/xdocs/"/>
  <index uri="index.xml"/>
  <dreams uri="dreams.xml"/>
  <faq uri="xmldb:xindice://localhost:4080/db/faq">
    <how_can_I_help uri="/how_can_I_help"/>
    <building_own_website uri="/building_own_website"/>
  <slashdot uri=""/>
  <javadocs uri="file:../javadocs/index.html"/>

Here are some mappings this sitemap provides:

site:/site                    file:./content/xdocs
site:/site/index              file:./content/xdocs/index.xml
site:/site/dreams             file:./content/xdocs/dreams.xml
site:/site/faq/how_can_I_help xmldb:xindice://localhost:4080/db/how_can_I_help

The lookup algorithm is:

 - Strip off the 'site:'
 - Locate the linkmap node identified by the remaining Xpath expression
 - For each ancestor-or-self:: node, up to one specifying a protocol:
   - Prepend the @uri attribute to a string S
 - return the final string S

> I'm still conceptually a bit confused how linkmap fits into the overall
> Cocoon sitmap structure.
> The indention of a sitemap is to map from the uri-space to the resource 
> content.
> The linkmap gives a more fine grained control over the mapping behaviour, is
> this correct?

Yes. With a linkmap, we have:

Sitemap: maps renderings (*.html, *.pdf etc) to abstract "site:" urls
Linkmap: maps "site:" urls to real source URLs (http:, file:, xmldb: etc)

So a linkmap just provides a level of indirection. Pretty simple.

However, the linkmap also needs to be able to act as an inverted sitemap:

Linkmap: maps "site:" urls to renderings (*.html, *.pdf etc) 

This is the hard part, but absolutely necessary.

One way to do it is to reverse-engineer the sitemap. Given a sitemap
S, work out it's inverse, S'.

Alternatively, one could generate _both_ sitemap and linkmap from
another, very general file. Perhaps a UML diagram?  That's where your
post was interesting :)

> I hope I could help a bit....

It was useful and thought-provoking. Thanks


> bye bernhard

View raw message