cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: [RT] Link Rewriting
Date Tue, 29 Apr 2003 19:16:18 GMT

On Monday, April 28, 2003, at 09:06 PM, Stefano Mazzocchi wrote:

> on 4/28/03 9:16 AM Jeremy Quinn wrote:
>> Hi All
>> Welcome to my first RT!
> Happy to see this. :-)

It has got an interesting set of responses too :)

>> Sorry to start on a negative note, but IMHO, the current scheme for
>> LinkRewriting just does not make sense for dynamic sites.
> Sorry, but what is the current scheme for link rewriting? I'm probably
> missing something.

see: http://localhost:8888/samples/linkrewriter/welcome

>> What the current scheme allows is for authors to use a simple set of
>> declarators for defining links, which are then translated into actual
>> URLs, (and in the samples) mapped directly to filespace (etc.).
> Uh? what do you mean?

Since the current incarnation of LinkreWritingTransformer came from the 
needs of Forrest (I believe), and Forrest is designed to output a 
static site, the mapping is for the convenience of Authors .... writing 
an easier-to-remember link, that gets mapped to a published URL.

When you apply LinkRewriting to a dynamic situation, the mapping you 
want to do changes in orientation.

>> What I believe a LinkRewriting infrastructure should offer is rather
>> different.
>> Cocoon's sitemap is excellent at disconnecting any direct relationship
>> between URL and resource ID/Path (SystemID). Allowing the
>> re-implementation of storage schema independently of URL contract.
>> What I feel makes more sense is this:
>> 	URL == permanent contract == authoring link != SystemID
> Wait a second.
>  URI -> uniform resource identifiers = permanent contract that
> identifies uniquely the resource in a uniform manner.
>  URL -> uniform resource locator = address used to locate the resource.
> Cocoon makes it easy to allow your URIs to be URLs.

Yeah, sorry, I never really grokked the difference between them ;)
> The problem with the above is that URLs and URIs are easy to
> discriminate if they are absolute. Not so if they are relative.
>> What this means is, authors should write links using a static absolute
>> URL, the same one as the public contract for that particular piece of
>> information.
> Yes, but this makes relocability hard.

Umm, not so I have noticed ....

>> When that URL is accessed, it should be mapped to a SystemID, allowing
>> independent re-implementation of the storage layer.
> I don't see this. doesn't the sitemap give you enough decoupling
> capabilities already?

It provides excellent facilities, but depends on how different they are.
In most cases, yes .... I managed to do the whole inIVA site in a 
pretty simple SiteMap, with various Sources and a legacy URL space to 
contend with.

The KISS site ( however is completely mapped by a 
LinkMap, because I wanted to allow SystemIDs to be completely different 
from URLs.

Why? One reason was because I often want the same info in different 
This means there are 2 different URLs within different hierarchal 
relationships, but coming from the same source, without special 
handling in the SiteMap.

The KISS LinkMap:
	is hierarchal
		- it provides the basis of the site menu child/parent relationships
	maps URIs to SystemIds
		- disassociates URL from Source
	is an Extended XLink with:
		Locators - both internal and external
		Arcs - aliases referring to another Locator
		Resources - names and static links

>> Does this make any sense to anybody?
> Yes and no.
> can you make an explicit example?

Lets say you wanted to serve the Source of different Author's documents 
from their own folders, with file names of their choosing, while retain 
control over a unified URL Space, without lots of rules embedded in the 

  <loc xl:label="home" xl:href="users/stef/domus-03.xml"
    xl:title="Stefano looks after the home page">
   <name>Home Page</name>
   <loc xl:label="about" xl:href="users/jerm/About the Site v2.xml"
     xl:title="Jeremy looks after the about page">
    <name>About the Site</name>
    <loc xl:label="who" 
      xl:title="Nicola Ken writes about the team">
     <name>Who writes the Site</name>
     <loc xl:label="about/stefano" xl:href="users/nico/stefano.xml"
       xl:title="Nicola Ken writes about Stefano">
      <name>About Stefano</name>
     <loc xl:label="about/nicola" xl:href="users/nico/sono.xml"
       xl:title="Nicola Ken on himself">
      <name>About Stefano</name>
     <loc xl:label="about/jeremy" xl:href=""
       xl:title="Jeremy is elsewhere">
      <name>About Jeremy</name>
    <loc xl:label="how" xl:href="users/stef/cocoon-2.1dev-06.xml"
      xl:title="Stefano writes about Cocoon">
     <name>How does the Site work</name>
     <ref xl:href=""
       xl:title="A static child link in the menu">
      <name>Cocoon Home</name>
   <arc xl:label="home/auth" xl:to="about/stefano"/>

This is similar to what I do on the KISS site.

I hope it's a bit more clear.
This type of mapping is useful when the URL space, Site hierarchy and 
Source space are not in any way similar.

regards Jeremy

"Objective reality is a synthetic construct, dealing with a 
hypothetical universalization of a multitude of subjective realities."
Philip K Dick - "The Electric Ant"

View raw message