cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Link Rewriting
Date Mon, 28 Apr 2003 20:06:23 GMT
on 4/28/03 9:16 AM Jeremy Quinn wrote:

> Hi All
> Welcome to my first RT!

Happy to see this. :-)

> 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.

> 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?

> 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.

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.

> 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?

> If this is to be handled by an input module accessing a linkmap (before 
> Generation, rather than during Transformation), but requires that 
> dynamic sitemap URL fragments can be passed to input modules (as they 
> cannot currently).
>   see: <>
> The transformation stage is then merely one of relativising author's 
> URLs.
> Most of what I have described here, is how most people use Cocoon.
> What is new here is the use of a LinkMap at the Generation stage to 
> de-couple URL from SystemID in a totally arbitrary way. A version of 
> the LinkMap idea that makes sense for Dynamic sites. This is what 
> requires changes to the way we are able to use input modules, as input 
> modules would provide a much cleaner path to handle this rather than 
> Transforming a generated LinkMap into CInclude tags to get the content.
> Does this make any sense to anybody?

Yes and no.

can you make an explicit example?


View raw message