You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2002/01/04 19:42:11 UTC
Summorizing Allowed Sitemap Constructs
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> 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. 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
like
overkill to me, but sometimes can be useful (especially in subsitemaps).
I'm
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
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.
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
2.0?
> Or do we have any bugs?
I see that some of us agree that we have bugs. Let's identify bugs which
we
are going to fix. Please place your comments/votes.
Regards,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Summorizing Allowed Sitemap Constructs
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Vadim Gritsenko wrote:
> >
> > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > >
> > > - 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.
Ok, yes, it might be correct - do not remember original design
in much details :)
What I meant is it looks to me like it is not logical.
> > 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?
Actually, I'm surprised that people are to add actions first, not
selectors.
Selectors look like first and obvious choice for promoting them as
first-class
sitemap citizens: I do not see lots of difference between them and
matchers.
Consider an example of root sitemap:
<map:select type="host">
<map:when test="www">
<map:mount/>
<map:when/>
<map:when test="one">
<map:mount/>
<map:when/>
<map:when test="two">
<map:mount/>
<map:when/>
<map:otherwise>
<map:mount/>
<map:otherwise/>
</map:select>
And creating WildcardURISelector and RegexpURISelector does not look
like
a challenge.
Don't you think that matchers and selectors should have same rights?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Summorizing Allowed Sitemap Constructs
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
>
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > 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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org