forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Linking revisited: A general linking system
Date Mon, 14 Oct 2002 13:04:45 GMT

Jeff Turner wrote:
> Congratulations if you got this far.  As I said, I was hoping to
> prototype it to clarify the ideas in my head before expecting others
> to read them, but a month later I was simply forgetting the details,
> so this braindump is as much for my benefit as anyone else.
> Ideas most welcome.  

I buy it :-)
But with some changes ;-)

Instead of links and URI space, which must be defined well in the 
sitemap (@see <first-impression-comment/> at the end) I see the linkmap 
used as a resource-map, where I can compose my *resource* space (ie the 
internal view, that is generally the filesystem) by mounting different 

This would give me the possibility of mixing and changing doc locations.

For example:

    <mount space="/javadocs" resource="file://../../tools/javadocs">
    <mount space="/" resource="file://.">

In this case I've attached a different dir to the resource tree, in a 
way similar to unix mounts (ok, it's the same ;-P ).

Then I could offload some stuff to xmldb:

    <mount space="/javadocs"

    <mount space="/code/sourcedocs"

    <mount space="/"

This does not however dictate anything about the URI space, which is 
defined in the sitemap and the real paths to the files-resources, where 
they should remain IMHO.

A linkmap should IMHO instead define *associations* between URIs, and a 
general site structure to be used by the user.
Which is not the URI space per-se; it defines more a book-view than a 
list of links.

For example (still need to elaborate more on this), for Cocoon we would have

  <linkmap uri="welcome">
    <link name="Using Cocoon" uri="cocoon/using">
      <link name="What is it?" uri="whatis/cocoon"/>
      <link name="Live sites" uri="links/live-sites"/>
    <link name="Apache" uri="" />

This would be used as a navigation system for all pages, and the 
book.xml as an alternative one, with both on the left side, as already 
suggested by me in prev threads.


All seems really nifty... but then I read it again, and I get the strong 
feeling that the linkmap is just another sitemap.

I can implement it by making the first part of the sitemap match the 
linkmap version of the links and redirect to a more "URLish" concrete 
Which basically defeats the whole purpose of the sitemap, which is to do 
this mapping from the beginning, and keep a consistent URI space.

What the sitemap does is to map a URI with a resource and operate on it 
via a pipeline.
The browsers should always show the URI that has been requested, which 
is the one that is linked.
It should be all consistent for the user.

The CAP concept is there to enable this concept by detaching URI-space 
from content-type resolution.
In this way the URI space is used for the conceptual URI space, while 
the content itself used to infer the right pipeline to use.

I don't see honestly what this brings us more than a sitemap itself can 
give, apart from URL rewriting without touching the sitemap itself. I 
honestly don't see the need for this ATM

Our problem with links and such is about mounting external URI spaces.
For example, I would like to be able to mount the //dir/to/javadocs 
resources in my resource system, so that *that* dir is used instead of 
the one relative to the Cocoon webapp dir.

Hmmm... so instead of URL rewriting it's *resource* rewriting...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message