Summary:
Developing Forrest, I seem to have stumbled in the need of mounted pipelines that do not halt processing if a match is not found.
Thus I propose that we add the pass through='true|[false]' attribute to make it possible for mounts not to necessarily halt processing if no match is found.
-=--=--=--=--=- Rationale:
It's typical to use the URL space to partition *processing*; because of this it's natural to match a URL in the base sitemap and delegate subURLs to mounted sitemaps.
In Forrest we have decided not to do this, and to keep the whole URI space free for uses to fill with their semantical partitionings. To decide how to process a file we use file extensions and eventually
peek inside to take a look at the DTD. This makes it impractical to
partition the sitemap in several mounted sitemaps.
It shifted from impractical to impossible as soon we tried to make it possible for users to add their sitemap to the processing. There is no clean way i know of ATM for me to delegate a part of the matches to an external sitemap without giving away a whole URL space. ATM we are asking users to *copy* the sitemap they want to use and change it, but it has already proved over time to be extremely fragile for updates. We do not want to keep such a lame contract with our users.
I hoped that calling the user pipeline with the cocoon: protocol and using a resource-exists could route round the issue, but it's still not ok. If a match is found, I have to process the pipeline two times, or rely on caching, which is not always possible or desirable.
So it seems that the only viable solution is to make it possible for mounted pipelines to not fail processing if a match is not found, and have the base sitemap resume processing. This is in line with what resources do now (in an unwanted but nevertheless welcome and happily used bug). James also has a similar thing in the mail pipeline matches, that can <passThrough>.
Thus:
I propose that we add the passthrough='true|[false]' attribute to make it possible for mounts not to necessarily halt processing if no match is found.
The proposed element for it is the <mount> node, so that the base sitemap has the say on whether it wants to make the subsitemap completely responsible or not of the subsequent processing. The default behavior would be identical to what we have now.
WDOT?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------