Re: [RT] Improved matching & selecting
On Dec 10, 2006, at 3:29 PM, Alfred Nathaniel wrote: Simple enough, but only in Relax NG. This grammar cannot be transformed into a DTD. There isn't currently a sitemap DTD, is there? —ml—
Re: [RT] Improved matching & selecting
On Dec 8, 2006, at 2:39 PM, Alfred Nathaniel wrote:
Could you try to write a Relax NG schema sniplet (preferable in compact
notation) for validating your proposed syntax?
OK, I think this is it. Just a first swipe at it, I haven't tried
validating anything against it, I've just run it through trang and
that's all so far. Not much to it, huh? :-)
Cheers,
—ml—
sitemap-matcher-engine.rnc
===
grammar {
start = Match
MatchType =
"exact"
| "contains"
| "path"
| "regexp"
Match =
element match {
attribute value { text }
& (
Matchspec
| Alternative +
)
}
Matchspec =
InlineMatchspec
| Branch +
InlineMatchspec =
attribute MatchType { text }
Branch =
element MatchType { text }
Alternative =
element when { Matchspec }
}
=
Re: [RT] Improved matching & selecting
On Dec 8, 2006, at 2:39 PM, Alfred Nathaniel wrote: Could you try to write a Relax NG schema sniplet (preferable in compact notation) for validating your proposed syntax? Sure, great idea... I'll take a swipe at that before I start any coding. best, —ml—
Re: [RT] Improved matching & selecting
On Fri, 2006-12-08 at 14:07 -0800, Mark Lundquist wrote: ... > > > 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— Could you try to write a Relax NG schema sniplet (preferable in compact notation) for validating your proposed syntax? Cheers, Alfred.
Re: [RT] Improved matching & selecting
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., ) 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 and would have conditioned users
to interpret and 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? :-)
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 , 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—
Re: [RT] Improved matching & selecting
On Tue, 2006-12-05 at 07:58 -0800, Mark Lundquist wrote:
> On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote:
>
> Or use different tags, say in resemblance to XSLT:
>
>
> ...
>
>
>
>
>
> I'm not so keen on that, 'cause I'm actually trying to get away from
> using 2 different elements for this. Rationale:
>
> 1) The precedent of and would have conditioned users
> to interpret and 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?). So I
don't see the problem in using Matcher implementations for more than one
tag which is not called map:match.
> 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. For example: in XSLT and , the @test clause
> contains a predicate. This is fundamentally different then in the
> sitemap, where the corresponding attribute contains a pattern, and the
> predicate comprises some kind of (implicit or configured) match of
> this pattern against a configured target value. Now the way this is
> expressed in the "classic" sitemap, the version puts
> this value into an attribute called "test" — probably, again, in
> deference to XSLT, and IMHO confusing — while the version puts
> it in an attribute called "pattern". But in either case, the
> semantics are rather different than XSLT owing to the difference
> between "predicate" and "pattern".
Well, why not really use XSLT syntax?
where wcmatch() and uri() are Cocoon components.
> 3) I think XSLT got it wrong :-). They should have used something
> like "" for both, and treated @test like I treat @value in
> my proposal. An analogy between and a "switch" or "case"
> statement is flawed, the correct analogy is to "if()... else if()" —
> again, because of the distinction between predicate and pattern!
> Switch/case is really like today's !!! "if()..."
> inaugurates a conditional using the same keyword regardless of how
> many alternatives there are — one, or many. That's how sitemap
> matching (which has only patterns) should do it, and that's how XSLT
> (which has only predicates) should have done it. No need for two
> different keywords.
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.
Whether the keyword pair is match/select or if/choose or cond/switch or
something else I don't care too much.
> cheers and thx for the feedback :-),
> —ml—
Cheers, Alfred.
Re: [RT] Improved matching & selecting
Hi Alfred,
On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote:
Or use different tags, say in resemblance to XSLT:
...
I'm not so keen on that, 'cause I'm actually trying to get away from
using 2 different elements for this. Rationale:
1) The precedent of and would have conditioned users
to interpret and 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.
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.
For example: in XSLT and , the @test clause contains a
predicate. This is fundamentally different then in the sitemap, where
the corresponding attribute contains a pattern, and the predicate
comprises some kind of (implicit or configured) match of this pattern
against a configured target value. Now the way this is expressed in
the "classic" sitemap, the version puts this value into
an attribute called "test" — probably, again, in deference to XSLT, and
IMHO confusing — while the version puts it in an attribute
called "pattern". But in either case, the semantics are rather
different than XSLT owing to the difference between "predicate" and
"pattern".
3) I think XSLT got it wrong :-). They should have used something like
"" for both, and treated @test like I treat @value in my
proposal. An analogy between and a "switch" or "case"
statement is flawed, the correct analogy is to "if()... else if()"
— again, because of the distinction between predicate and pattern!
Switch/case is really like today's !!! "if()..."
inaugurates a conditional using the same keyword regardless of how many
alternatives there are — one, or many. That's how sitemap matching
(which has only patterns) should do it, and that's how XSLT (which has
only predicates) should have done it. No need for two different
keywords.
cheers and thx for the feedback :-),
—ml—
Re: [RT] Improved matching & selecting
On Mon, 2006-12-04 at 08:34 -0800, Mark Lundquist wrote: > On Dec 4, 2006, at 7:37 AM, Bertrand Delacretaz wrote: > > > Restricting a single sitemap to use either of these engines (as > > opposed to allowing a mix in a single sitemap) might help avoid > > confusion. > > I totally agree! > > How about... > > > > This would be the default setting, to preserve backward-compatibility. > It would also log a message to the deprecation log! > > vs.: > > > > I'm also thinking that with matching="engine", we should get rid of the > section in the sitemap altogether, and set up the matching > engine component in cocoon.xconf. WDYT? > > cheers, > —ml— Or use different tags, say in resemblance to XSLT: ... ... map:match and map:select can the be deprecated and removed in a future version. Cheers, Alfred.
Re: [RT] Improved matching & selecting
On Dec 4, 2006, at 7:37 AM, Bertrand Delacretaz wrote: Restricting a single sitemap to use either of these engines (as opposed to allowing a mix in a single sitemap) might help avoid confusion. I totally agree! How about... This would be the default setting, to preserve backward-compatibility. It would also log a message to the deprecation log! vs.: I'm also thinking that with matching="engine", we should get rid of the section in the sitemap altogether, and set up the matching engine component in cocoon.xconf. WDYT? cheers, —ml—
Re: [RT] Improved matching & selecting
On Dec 3, 2006, at 1:27 PM, Mark Lundquist wrote:
7) There would be a globally configurable property to take the place
of the local @value attribute. To invoke a (non-default) configured
instance, you use just like today, but that is not
any lighter syntactically than just using @value. The real reason for
this is to be able to configure a more specific default, e.g.
{request:URI}
This allows you to just write
which is nearly identical to today's
where . The tradeoff is that you then
have to use for anything else... but you have
the choice if you want to do it that way.
Bah, I still had some "old skool" thinking goin' on there myself...
Instead of a configuration element that precludes a local
@value attribute, the element should be called and it
should just configure a default if @value is omitted. You can still
override the default with @value. So:
—ml—
Re: [RT] Improved matching & selecting
On 12/4/06, Mark Lundquist <[EMAIL PROTECTED]> wrote: .. if a user is trying to use a "classic" matcher and they bungle the 'pattern' attribute, the resulting error message will be confusing because it will be coming from the "new style" matcher... You could also make things more explicit and use a per-sitemap instruction or namespace to switch between the old and new matching engines. Restricting a single sitemap to use either of these engines (as opposed to allowing a mix in a single sitemap) might help avoid confusion. -Bertrand
Re: [RT] Improved matching & selecting
On Dec 4, 2006, at 7:22 AM, Peter Hunsberger wrote: On 12/4/06, Sylvain Wallez <[EMAIL PROTECTED]> wrote: Mark Lundquist wrote: > Hi gang, > So... WDYAT? +1. Lots of good ideas! I even think it may be implemented in a backwards compatible way, by switching between the two approaches depending on the existence of a "pattern" attribute, and thus go in a 2.2.x release. Yes, if that is done then +1 The only thing that troubles me about that approach is the unintended consequence... if a user is trying to use a "classic" matcher and they bungle the 'pattern' attribute, the resulting error message will be confusing because it will be coming from the "new style" matcher (or its node builder). It'd be nice to figure out a graceful solution for this case... but if not, then I guess "oh, well" :-) —ml—
Re: [RT] Improved matching & selecting
On 12/4/06, Sylvain Wallez <[EMAIL PROTECTED]> wrote: Mark Lundquist wrote: > Hi gang, > So... WDYAT? +1. Lots of good ideas! I even think it may be implemented in a backwards compatible way, by switching between the two approaches depending on the existence of a "pattern" attribute, and thus go in a 2.2.x release. Yes, if that is done then +1 -- Peter Hunsberger
Re: [RT] Improved matching & selecting
On Dec 4, 2006, at 1:29 AM, Sylvain Wallez wrote: I even think it may be implemented in a backwards compatible way, by switching between the two approaches depending on the existence of a "pattern" attribute, and thus go in a 2.2.x release. Good idea... yes, I think that would be possible. —ml—
Re: [RT] Improved matching & selecting
Mark Lundquist wrote: > Hi gang, > So... WDYAT? +1. Lots of good ideas! I even think it may be implemented in a backwards compatible way, by switching between the two approaches depending on the existence of a "pattern" attribute, and thus go in a 2.2.x release. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Improved matching & selecting
On 12/3/06, Mark Lundquist <[EMAIL PROTECTED]> wrote: ...So... WDYAT?.. I like your proposal, there are probably some details to iron out but I'd like to say: go for it! It might be a good opportunity to try building the smallest (embeddable?) Cocoon that can run pipelines, by implementing your proposal and plugging a minimal set of existing components into it. -Bertrand
Re: [RT] Improved matching & selecting
On Monday 04 December 2006 06:02, Mark Lundquist wrote: > I see that this would have to wait 'til C3, according to > http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1181.html And in a future C3, could it be possible that the entire sitemap is abstracted out, a. into a standalone component, b. with a stricter programmatic interface as its primary API, both for re-use in other projects as well as easier changes in the future? Anyway, I like your effort... Cheers Niclas
Re: [RT] Improved matching & selecting
I see that this would have to wait 'til C3, according to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1181.html —ml—
