cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist>
Subject Re: [RT] Improved matching & selecting
Date Fri, 08 Dec 2006 22:07:29 GMT

Hi Alfred,

On Dec 5, 2006, at 3:21 PM, Alfred Nathaniel wrote:

> On Tue, 2006-12-05 at 07:58 -0800, Mark Lundquist wrote:
>> I'm not so keen on that, 'cause I'm actually trying to get away from
>> using 2 different elements for this.
N.B.,  it looks like you might have misread the above as "components", 
instead of "elements".  I regard collapsing matching/selecting syntax 
to originate with a single type of element (viz., <match>) as a 
positive good and a primary goal, not a just an after-effect of any 
implementation consideration (though I am pleased that it can also be 
done with a considerable simplification and reduction of existing 

>> 1) The precedent of <match> and <select> would have conditioned users
>> to interpret <if> and <choose> as referring to two different kinds of
>> sitemap components ("Iffer"s and "Choose"rs? :-).  I'd like the syntax
>> to emphasize that it's all matching and there is only one component
>> now, The Matcher.
> There is no need for a one-to-one relation between sitemap tags and
> components.  (There won't be any Whener in your model either?).

Yes, well you know that and I know that :-)... what I was trying to say 
is that users expect a certain relationship between elements and 
components in the area of matching and selecting, because it's been 
that way in all the history of Cocoon, at least as far back as most 
people know (certainly true for me :-).  I think you missed my entire 
point of (1); I wasn't at all saying that I felt the use of a single 
matching component constrains me to use a single XML element in the 
sitemap.  Anyway, that was the least important consideration, I should 
probably have listed it last instead of first! :-)

> So I don't see the problem in using Matcher implementations for more 
> than one
> tag which is not called map:match.

Yes, there is (technically) is no problem in doing this.  The 
difference is that you view it as desirable, while I do not! :-)

>> 2) The sitemap language is not XSLT and has nothing to do with XSLT.
>> The only relationship is that the sitemap has to do with Cocoon and
>> Cocoon uses XSLT... big deal! :-)  Trying to imitate XSLT in the
>> sitemap in the interest of familiarity IMHO is misguided and results
>> in confusion.  Things that are different should look and feel
>> different.  [snip...]
> Well, why not really use XSLT syntax?

errm... see above? :-)

>     <map:if test="wcmatch(uri(), '**/*.xml'">
> where wcmatch() and uri() are Cocoon components.

OK, I am not keen on inventing a novel syntactic form in the sitemap, 
especially for little or no benefit.  IMHO, the introduction of a novel 
syntactic form should be considered only when necessary to deliver a 
_compelling_ benefit.  Also, implementing it with this 
pseudo-expression-language syntax is more work than I want to do, but 
that's a secondary consideration.  (It would require a greater volume 
of code, which is more important than the consideration of effort but 
still secondary to the usage complexity vs. benefit tradeoff).

I also don't like how it suggests to the user that there is some kind 
of generalized expression language available, when in fact there is not 
(nor do I think there should be)... so it turns out to just be a facade 
that exists for the sake of being able to have a _less_ meaningful 
attribute name ("test", as opposed to "equals", "path", etc.).

I'll grant that this suggestion does, in a perverse way, make the 
attribute name "test" itself slightly less objectionable than it is now 
in <select/when>, since the contents of the attribute would then read 
as a predicate.  But I think overall, it'd be a step in the wrong 

> I think we should use two different keywords because otherwise the
> content model depends on the presence of various attributes and not on
> the tagname only -- that is really confusing.

To my mind, a special element to distinguish conditionals having 
exactly 1 alternative is no more desirable than a special element to 
distinguish conditionals having exactly two alternatives, or three, or 
any other number; that is to say, not desirable at all.  In the scheme 
I've proposed, it's very easy (and to me, natural) to tell how many 
alternatives a matcher has.

best regards,

View raw message