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]
