cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Escaping Sitemap Hell
Date Fri, 07 Jan 2005 09:49:49 GMT
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>> A real map for the site should be tree structured like the linkmap in 
>> forrest. Take a look at the example in [1], (I don't suggest using the 
>> "free form" XML, something stricter is required). Such a tree model 
>> will also help in planning the URI space as it gives a good overview 
>> of it.
> Forrest and cocoon serve different purposes.
> While I totally welcome the fact that Forrest has such "linkmaps", I 
> don't think they are general-enough concepts to drive the entire 
> framework. They are fine as specific cases, especially appealing for a 
> website generation facility like forrest, but as a general concept is 
> too weak.

While I agree with your reply, I think that I understand what problem 
Daniel thinks he sees.

  A sitemap is not the _map_ of a _site_.

That's why we made site.xml.

But saying that this should drive processing is IMHO not correct. In 
fact, it's the opposite. We made the site.xml stuff in a different file 
so that it would *not* interfere with processing.

>> Choosing Production Pipeline
>> ----------------------------
>> Now instead of having the rule:
>> *.x.y.z ==> XYZPipeline
>> we have
>> * where repository:{1} have properites {x, y, z} ==> XYZPipeline
>> or
>> * where repository:{1}.x.y.z exists ==> XYZPipeline
> Oh, a rule system for sitemap!
> hmmmm, interesting... know what? the above smells a *lot* like you are 
> querying RDF. hmmmm...

At Forrest, we have done a similar thing, and are still in the process 
of finishing it. IT states something like this:

  "Forrest processing should not be tied to URLs."

IOW, Forrest should not process a file differently just because it's in 
a particular directory, but using other characteristics, like mime-type, 
DTD, schema, etc. For us, an URL is a partitioning decision of the 
content creator, not of the application creator.

Many sites fail to do this, and URL matching has become the easiest way 
of partitioning Cocoon's processing, although not the best.

You can make your own matcher... and here is where we should 
concentrate, by defining new blueprints that don't use the URL as a 
matching system.

Forrest is doing it for docs... someone else can do it for apps :-)

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

View raw message