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 15:56:55 GMT
On Mon, Oct 14, 2002 at 03:04:45PM +0200, Nicola Ken Barozzi wrote:
> 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 
> spaces.
> This would give me the possibility of mixing and changing doc locations.
> For example:
>  <resourcemap>
>    <mount space="/javadocs" resource="file://../../tools/javadocs">
>    <mount space="/" resource="file://.">
>  </resourcemap>
> 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:
>  <resourcemap>
>    <mount space="/javadocs"
>           resource="file://../../tools/javadocs">
>    <mount space="/code/sourcedocs"
>           resource="myprotocol:/path/to/docs">
>    <mount space="/"
>           resource="file://.">
>  </resourcemap>

Yes, that's the idea.  Probably 'resourcemap' is a better name than
'linkmap', given your definition of a resource:

  "What the sitemap does is to map a URI with a resource and operate on
  it via a pipeline."

> This does not however dictate anything about the URI space, which is 
> defined in the sitemap

Correct, it's just an alias for a filesystem resource. URI space !=
resource space.

> and the real paths to the files-resources, where they should remain

I didn't get this bit. So how would we use this resourcemap? Isn't the
sitemap the thing that uses it, with matchers like:

<map:match pattern="*.html">
  <map:generate src="resourcemap:/code/sourcedocs/{1}"/>

If so, I think we'll agree that a) there's nothing revolutionary about
this (it was part of Marc's siteplan), b) it doesn't reeeally get us too
far on it's own. In our pages, we still need to link to foo.html, not
foo.xml or just 'foo'.

> A linkmap should IMHO instead define *associations* between URIs, and a 
> general site structure to be used by the user.

(I'm assuming user = person browsing the site)

> Which is not the URI space per-se; it defines more a book-view than a 
> list of links.

How can it not be the URI space? If page A has <link href="blah.html">,
then blah.html is a URI reference, isn't it? Likewise with book.xml: it
also deals only with URIs.

> 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>
>    <link name="Apache" uri="" />
>  <linkmap>
> This would be used as a navigation system for all pages

How? Would we have links like <link href="cocoon/using">? If so, what
does this linkmap buy us?

> , and the book.xml as an alternative one, with both on the left side,
> as already suggested by me in prev threads.

Here's a trail of thought...

Let's call the following a 'map':


Q: What can we do with this?
A: We can hang things off it.

A 'resourcemap':

<site res="file://.">
  <index res="index.xml"/>
  <primer res="primer.xml"/>
  <faq res="faq/">
    <how_can_I_help res="xpath:/faqs/faq/question[@id='...']"/>
  <javadocs res="file://../../javadocs"/>

A 'URImap':

<site uri="http://localhost:8080/mysite">
  <index uri="index.html"/>
  <primer uri="primer.html"/>
  <faq uri="faq/">
    <how_can_I_help uri="#how_can_I_help"/>
  <javadocs uri="javadocs/"/>

A 'TitleMap':

<site desc="My Wonderful Site">
  <index desc="Index"/>
  <primer desc="Forrest Primer"/>
  <faq desc="FAQ">
    <how_can_I_help desc="How can I help?"/>
  <javadocs desc="API Docs"/>

What makes this 'map' interesting?
You can hang all sorts of stuff off it.
And address it all in the same way.
Via XPath expressions.
Isn't that neat?

Exercise for the reader:

 - Use the above to solve the problem of linking to things like Javadocs,
   where we don't want to hardcode the URL to a resource.

 - Use the above to solve the "linking problem": that is, How do we avoid
   linking to URIs like "blah.html", which presupposes and hardcodes a
   blah.xml -> blah.html mapping, and is generally yucky.

 - Describe why, although these problems could be solved with custom
   formats (resourcemap, linkmap, book.xml), solving them all at once
   with the single 'map' idea is more elegant and easier for users.

That's the underlying thinking behind what I was erroneously calling a


>        ->->->->->->->->->->->->->->->->->->->->->->->->->
> <first-impression-comment>
> 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 
> version.
> 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...
> </first-impression-comment>
> -- 
> Nicola Ken Barozzi         
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

View raw message