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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------