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
code).
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
direction.
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,
—ml—
