Vadim Gritsenko wrote:
> 
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> >
> > Hi,
> 
> Hi Carsten and all,
> 
> >
> > before we continue discussion things like pre/intra/post-matching
> actions,
> > can someone summarize the current semantics of the sitemap as it
> *should*
> > 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
> in
> current sitemap implementation. I will put my suggestions below.
> 
> >
> > - only match is allowed as top-level element
> 
> It is not correct. 

No, it *is* correct. You are proposing to change what the original
design was (which is totally fair) but it's wrong to state that the
above is incorrect.

> 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.

ok, for act, but select?
 
> Allowing map:generate, map:transform, map:serialize, and map:read looks
> like
> overkill to me, but sometimes can be useful (especially in subsitemaps).
> I'm
> somewhere around -0.5 on this.

-1 verbosity sometimes is useful, provides context and
autodocumentation.
 
> > - 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
> test
> >             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.

Agreed.

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

Same here, it would make pipelines too complex and would inhibit the use
of internal redirection (cocoon: protocol) which is a good way, IMO, to
suggest the use of SoC patterns inside your URI space.
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<[EMAIL PROTECTED]>                             Friedrich Nietzsche
--------------------------------------------------------------------



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

Reply via email to