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]