cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject Summorizing Allowed Sitemap Constructs
Date Fri, 04 Jan 2002 18:42:11 GMT
> From: Carsten Ziegeler []
> Hi,

Hi Carsten and all,

> before we continue discussion things like pre/intra/post-matching
> can someone summarize the current semantics of the sitemap as it
> be? I can only describe it, as it is currently implemented:

It seems to me - and to others on the list too - that we have some bugs
current sitemap implementation. I will put my suggestions below.

> - only match is allowed as top-level element

It is not correct. I propose to allow following constructs:
 * map:match
 * map:select
 * map:act
I'm +5 on this, and can help implement this if everybody agrees.

Allowing map:generate, map:transform, map:serialize, and map:read looks
overkill to me, but sometimes can be useful (especially in subsitemaps).
somewhere around -0.5 on this.

> - the sitemap is processed top-down, the processing stops:
>   * when a serialize is reached
>   * when a reader is reached
>   * when the end is reached
> - match: if match successful, processing continues inside
> - select: if a test is successful, processing continues inside this
>             else processing continues in otherwise
> - act: action is executed. If it returns something, processing
>           is executed inside the element
> - generate: generator is added to pipeline
> - transform: transformer is added to pipeline
> - serialize: serializer is added to pipeline, processing ends
> - reader: reader is added to pipeline, processing ends

This looks Ok to me; any changes here will break compatibility.

Another construct which is left behind is map:aggregate. Do we allow
matches/selectors/actions inside map:aggregate? We need to agree on what
we allow under map:aggregate:

Already there:
 * map:part
Other possible candidates:
 * map:match
 * map:act
 * map:select
I'm +1 on these additions.

Vote -1 goes to: 
 * map:generate/map:serialize/map:transform/map:read

> So the first question to answer is: is this the semantics wanted for
> Or do we have any bugs?

I see that some of us agree that we have bugs. Let's identify bugs which
are going to fix. Please place your comments/votes.


To unsubscribe, e-mail:
For additional commands, email:

View raw message