The following snippet is the guide example for the first two questions.

<map:pipeline>

<map:match pattern="sub/*">
<map:mount check-reload="yes" src="sub/sitemap.xmap" uri-prefix="sub"/>
</map:match>

<map:handle-errors>
<map:transform src="errors.xsl"/>
<map:serialize status-code="500"/>
</map:handle-errors>

</map:pipeline>

1) What is the accepted "correct" behavior for subsitemaps: errors in subsitemaps elicit errors up the chain to parent (sub)sitemaps or subsitemap validity has no bearing at all on parents?

If foo/sitemap.xmap is missing, is not well-formed XML, or is not valid, what should be the behavior for the sitemap that contains this pipeline if the "sub" URLs are not requested?


2) Does error handling confine itself only to the sitemap/pipeline in which it's defined or does it act more like exceptions that push up the chain?

Would errors in the subsitemap be caught in the parent's error handlers if the subsitemap error was not caught by its own handlers?


3) Do subsitemaps require a components section at all? Just defaults?

If so, why do they need to be specified in each subsitemap? Why not inherit the defaults of the parent if they're not specified? I ask because I'd like subsitemaps to be as small and simple for beginners as possible. Since their choice of components are determined by parents, both scenarios have a parent content dependency.


4) Is there any way (or proposed way) to specify that a sitemap resource have a fixed-duration cache validity?

Can you specify that a relatively dynamic resource should have its internal cache validity only expire after a fixed period of time, like an hour or a day? This is not just limited to headers (like the current "expires" attribute in 2.1), but rather for any resource.

A contrived example:

<map:match pattern="stockquotes.xml">
<map:generate type="serverpages" src="data_from_sql_taglib.xsp"/>
<map:serialize type="xml"/>
</map:match>

<map:match pattern="generalpublic.html">
<map:generate src="cocoon:/stockquotes.xml" expires="1 hour"/>
<map:transform src="stocks2html.xsl"/>
<map:serialize type="html"/>
</map:match>

<map:match pattern="subscribersonly.html">
<map:generate src="cocoon:/stockquotes.xml" expires="5 minutes"/>
<map:transform src="stocks2html.xsl"/>
<map:serialize type="html"/>
</map:match>

<map:match pattern="goldsubscribersonly.html">
<map:generate src="cocoon:/stockquotes.xml"/>
<map:transform src="stocks2html.xsl"/>
<map:serialize type="html"/>
</map:match>

Same resource...different cache granularity. It seems to me that this would be especially useful for aggregations -- especially aggregations of dynamic data. ...or is this technically in opposition to (and blocked by) the existing cache model that's based on hash keys? I think it would also solve a lot of the problems with complexity in XSP scripts since some authors wouldn't have to worry about putting cache validity (whose API has changed) in their code which may otherwise have just been taglibs.


Answers or clues to any or all of these questions would be greatly appreciated. :)

- Miles



---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to