Judson Lester wrote:
> There's been a brief exchange in the 'Allowed Sitemap Constructs' section
> (that I got the impression was not the first time it had been brought up),
> the gist of which was the the distinction between matchers and selectors was
> mostly arbitrary. It would be not terribly hard to merge the two without
> breaking back-compatibility.
Hmmm
> Essentially, that <match/> could occur in place
> of <when/> (which would be obsoleted, like the old style function
> declaraction in C), and that <select/> gain an optional attribute that
> allowed it to return maps (<select return-map="true"> ...</select>). At that
> point matchers and selects become completely interchangable, which might help
> to smooth the learning curve slightly, and ease implementation.
>
> Allowing, amongst other things,
> <select return-map="true">
> <match test="...">
> ....
> </match>
> <otherwise>
> ....
> </otherwise>
> </select>
>
> but in this case, if the <otherwise/> clause isn't needed, the wrapping
> select can be dropped, or not.
Hmmm, try to read it from the perspective of somebody who cames from
XSLT or comes from other programming languages. Which one has a easier
learning curve yours, or the one we already have?
Sure, matchers and selectors *DO* partially overlap.
But don't
for{};
while{};
do {} while ();
partially overlap?
As stated somewhere else, syntax sugar is not always bad.
And as far as implementation, it's pretty easy to write a Select and a
Matcher using the same logic behind it.
But there is more: semantic overlap triggers some deeper thinking about
'which one is better for this'?
The problem is when overlapping things are totally equivalent, but this
is *NOT* the case for matchers and selectors since the first perform
tokenization, while the second do not.
I'm very happy to provide strict and good rules about sitemap component
composition, but this won't necessarely mean that semantic overlapping
will be removed.
Moreover, matchers 'match a request' while selectors 'select paths'.
They clearly separate concerns! Their functionality and implementations
partially overlap because both require 'conditional operations', but one
is declarative (matchers) and one is procedural (selectors).
IMO, merging the two removes partial functional overlapping but
increases concern overlap.
> <snip/>
> >
> > In the example sitemap:
> >
> > <map:views>
> > <map:view name="view1" from-position="content">
> > <map:serialize type="s2"/>
> > </map:view>
> >
> > <map:view name="view2" from-position="last">
> > <map:transform type="t3" src="..."/>
> > <map:serialize type="s3"/>
> > </map:view>
> > </map:views>
> >
> > <map:pipelines>
> > <map:pipeline>
> > <map:generator type="g1" src="..."/>
> > <map:transformer type="t1" src="..." map:label="content"/>
> > <map:transformer type="t2" src="..."/>
> > <map:serializer type="s1"/>
> > </map:pipeline>
> > </map:pipelines>
> >
> > for any URI the views will do
> >
> > default (no view): g1 -> t1 -> t2 -> s1
> > view1: g1 -> t1 -> s2
> > view2: g1 -> t1 -> t3 -> s3
>
> Shouldn't view2 be g1->t1->t2->t3->s3? Otherwise I'm very confused.
Yeah, sorry, you got me there :)
> > Structure Validation
> > --------------------
> >
> > The sitemap should be checked for structure inconsistencies or mistakes
> > at load-time.
> >
> > Checks include:
> >
> > 1) all handled requests must pass thru a (generator|serializer) pair or
> > a reader.
> >
> > 2) readers must never find the other direct components during a
> > pipeline processing.
> >
> > 3) mount and redirect-to must never be found after a direct component.
>
> Is it out of line to propose a
> 4) actions (or perhaps, more generally, components) which can never be
> reached?
Good point. +1
--
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]
