You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jacek Ambroziak <ja...@yahoo.com> on 2002/02/21 04:24:04 UTC
XSLT benchmarks: dbonerow
Setting the stage:
Today's XSLTC translets perform abysmally on the
'dbonerow' benchmark.
The XML document is a set of 10^4 records and the
stylesheet contains
one template designed to match (and process) one of
the records;
XSLT essentially performs a search by matching.
On my machine 10 iterations of 'dbonerow' take
Saxon/XT/Xalan approx. 20 sec
compared to 7 times longer for a translet. The time
loss is so huge that
XSLTC looses all gains from other tests and comes
last.
Towards a better tomorrow:
I have rewritten XSL as follows:
<xsl:template match="row[id = '0432']">
stuff
</xsl:template>
to
<xsl:template match="row">
<xsl:if test="id = '0432'">
stuff
</xsl:if>
</xsl:template>
Now Saxon/XT/Xalan still need around 20 seconds
(although they too prefer
the second variant). A translet, however, takes only
0.5 second
(or even 68msec w/o printing output). Used to be 7
times slower
-- now is 40 times faster. This is shocking!
with this rewrite the magic numbers in my environment
are:
XSLTC 780
XT 482
Saxon 304
XalanJ 207
Obviously, the compiler is doing something VERY WRONG
for this test
(and presumably for 'patterns', 'decoy', etc.)
So there is hope.
Fixing the problem will not be easy; not only I've
forgotten many
implementation details, but the code has changed since
I last worked on it
(not always to my liking :-( )
--Jacek
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLT benchmarks: dbonerow
Posted by Robert Koberg <ro...@koberg.com>.
----- Original Message -----
>From: "Stefano Mazzocchi" <st...@apache.org>
> >Steven Noels wrote:
> >
> > > Robert Koberg wrote:
> > >
> > > You know... I wonder why you guys don't spend time on optimizing the
XSL (I
> > > know Steven Noels is). This is most probably the bottleneck you are
> > > experiencing?? You guys are taking the path away from general
adoption...
> > >
> > >
> > > ----- Original Message -----
> > > From: "Jacek Ambroziak" <ja...@yahoo.com>
> >
> > [...]
> >
> > > >
> > > > I have rewritten XSL as follows:
> > > >
> > > > <xsl:template match="row[id = '0432']">
> > > > stuff
> > > > </xsl:template>
> > > >
> > > > to
> > > >
> > > > <xsl:template match="row">
> > > > <xsl:if test="id = '0432'">
> > > > stuff
> > > > </xsl:if>
> > > > </xsl:template>
> > > >
> >
> > Well, I fully trust the judgment of Jacek here...
The above should use xsl:key
> >
> > Depending on your favorite brand of XSLT engine, I'm quite sure
different
> > optimalizations will be applied upon stylesheet execution. XSLTC has
been
> > available long enough inside Xalan to finally start using it, or at
least making
> > its usage possible & optional. It will be up to the classloading gurus
however
> > to tackle this one.
> >
> > I must say I'm quite stumped finding out how you should
rewrite/optimalize your
> > stylesheet in order to fully utilize XSLTC: predicates in XSLT Patterns
seem
> > like a different beast to me than an xsl:if construct, and one can not
be
> > trusted to keep this kind of optimalization in mind while authoring a
> > stylesheet.
> >
> > I'm quite sure this is not the intended behaviour of XSLTC, hopefully
Jacek
> > finds time to correct XSLTC on this.
> >
> > Anyway, another discussion which shows me XSLT has not yet proven to be
a highly
> > optimizable language, even though it has been created with
side-effect-freeness
> > in mind. And finally, something I learnt from Berin and other wise men
on this
> > list: one must not start with sourcecode optimalization targeting a
specific
> > runtime environment unless *all* other possibilities are exhausted. And
XSLTC
> > seems like a good possibility for the 'bad' (really?) XSLT performance
in
> > Cocoon.
I don't agree. Most people come to XSL thinking it is like JSP/ASP/etc. They
write XSLs that conforms to that thinking and it leads to slow/ugly XSLT.
>
> Which leads me to think: how hard/expensive would be for an XSLT
> processor to 'optimize' algorithmically the XSLT stylesheet?
I know Saxon does this. I usually find that Saxon is the best/fastest
(conformant) when the XSL is as clean as possible. I am not talking about
XSLTC because I think in terms of development of the site rather than
deployment, but I assume XSLTC could only benefit from an optimized XSL
(ASSumption).
<snip/>
>
> IMO, the best think would be to have an XSLT interpreter for your
> development cycles (where compliance and low latency are most important)
> and an XSLT compiler for production release (where runtime performance
> and scalability are the issues and low latency is not).
I like this. This should be codified into How to Use Cocoon or even into the
Way you have-to use cocoon.
>
> Add the ability to 'algorithmically optimize' the sytlesheet before
> compilation and I think that we have solved all our issues with XSLT
> performance.
>
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLT benchmarks: dbonerow
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
>
> Robert Koberg wrote:
>
> > You know... I wonder why you guys don't spend time on optimizing the XSL (I
> > know Steven Noels is). This is most probably the bottleneck you are
> > experiencing?? You guys are taking the path away from general adoption...
> >
> >
> > ----- Original Message -----
> > From: "Jacek Ambroziak" <ja...@yahoo.com>
> > To: <xa...@xml.apache.org>; <co...@xml.apache.org>
> > Cc: <st...@apache.org>
> > Sent: Wednesday, February 20, 2002 7:24 PM
> > Subject: XSLT benchmarks: dbonerow
> >
> >
>
> [...]
>
> > >
> > > I have rewritten XSL as follows:
> > >
> > > <xsl:template match="row[id = '0432']">
> > > stuff
> > > </xsl:template>
> > >
> > > to
> > >
> > > <xsl:template match="row">
> > > <xsl:if test="id = '0432'">
> > > stuff
> > > </xsl:if>
> > > </xsl:template>
> > >
>
> Well, I fully trust the judgment of Jacek here...
>
> Depending on your favorite brand of XSLT engine, I'm quite sure different
> optimalizations will be applied upon stylesheet execution. XSLTC has been
> available long enough inside Xalan to finally start using it, or at least making
> its usage possible & optional. It will be up to the classloading gurus however
> to tackle this one.
>
> I must say I'm quite stumped finding out how you should rewrite/optimalize your
> stylesheet in order to fully utilize XSLTC: predicates in XSLT Patterns seem
> like a different beast to me than an xsl:if construct, and one can not be
> trusted to keep this kind of optimalization in mind while authoring a
> stylesheet.
>
> I'm quite sure this is not the intended behaviour of XSLTC, hopefully Jacek
> finds time to correct XSLTC on this.
>
> Anyway, another discussion which shows me XSLT has not yet proven to be a highly
> optimizable language, even though it has been created with side-effect-freeness
> in mind. And finally, something I learnt from Berin and other wise men on this
> list: one must not start with sourcecode optimalization targeting a specific
> runtime environment unless *all* other possibilities are exhausted. And XSLTC
> seems like a good possibility for the 'bad' (really?) XSLT performance in
> Cocoon.
Which leads me to think: how hard/expensive would be for an XSLT
processor to 'optimize' algorithmically the XSLT stylesheet?
I mean: fast SQL implementations do this: transform the SQL in a
in-memory structure, then perform some algebraic analysis to obtain
*all* the possible ways to execute he same query (it's hard to formalize
it, but it's doable), then perform some statistical analysis on the
different 'strategies' in order to evaluate the potential algorithmic
cost of each one, then choose the cheapest one and compile that.
Now: XSLTC spends some time creating the translet, I'm pretty sure that
nobody would mind, in a server environment, at least, if XSLTC spent
even a second to find out the best strategy to compile the stylesheet.
Sure, for interpreted execution this might be too much of an overhead,
but for server side compiled execution (given the fact that stylesheets
rarely change in a production environment), the differences that Jacek
show are *huge* and could potentially lead to *incredible* performance
compared to other 'standard' solutions.
I think Scott is right saying that you can't go faster than something
when you are checking for everything in the stylesheet (compliance,
tracing, error cheching and so on) but who said this should be done at
runtime?
IMO, the best think would be to have an XSLT interpreter for your
development cycles (where compliance and low latency are most important)
and an XSLT compiler for production release (where runtime performance
and scalability are the issues and low latency is not).
Add the ability to 'algorithmically optimize' the sytlesheet before
compilation and I think that we have solved all our issues with XSLT
performance.
--
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
Re: XSLT benchmarks: dbonerow
Posted by Stefano Mazzocchi <st...@apache.org>.
Robert Koberg wrote:
>
> If you look at and evangelize the use of keys you will see performance
> increase DRAMATICALLY.
Yes, sure, but since most of these optimizations are algorithmical
(means that it's possible to write a program that does them for you, as
Scott suggested), why in hell should we spend time/effort/energy and
brain cells to do something that the XSLT processor should do for us?
It's like optimizing SQL: it's a black art.
The serious databases optimize the SQL for you, so the serious XSLT
prcessors should optimize the XSLT for you.
At least, that's how I see it.
--
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
Re: XSLT benchmarks: dbonerow
Posted by Robert Koberg <ro...@koberg.com>.
If you look at and evangelize the use of keys you will see performance
increase DRAMATICALLY. But, I understand you point. Thanks, Rob
----- Original Message -----
From: "Jacek R. Ambroziak" <ja...@yahoo.com>
<snip/>
> And then there are of course
> many stylesheets written by our users :-)
>
> The rewrite is of the form:
>
> if (A && B) { ... } --> if (A) { if (B) { ... }}
>
> If the second version is 300 times faster, then we've got
> something interesting going on here :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLT benchmarks: dbonerow
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
The rewrite experiment only shows that there is a *serious bug*
in the compiler code AND that there is *hope* for much improved
performance of translets testing conditions in template patterns.
'dbonerow' helped focus our attention. There are other tests (eg. decoy)
which seem affected by the same bug. And then there are of course
many stylesheets written by our users :-)
The rewrite is of the form:
if (A && B) { ... } --> if (A) { if (B) { ... }}
If the second version is 300 times faster, then we've got
something interesting going on here :-)
--Jacek
On Thursday 21 February 2002 04:22 am, Steven Noels wrote:
> Robert Koberg wrote:
> > You know... I wonder why you guys don't spend time on optimizing the XSL
> > (I know Steven Noels is). This is most probably the bottleneck you are
> > experiencing?? You guys are taking the path away from general adoption...
> >
>
>
> > > I have rewritten XSL as follows:
> > >
> > > <xsl:template match="row[id = '0432']">
> > > stuff
> > > </xsl:template>
> > >
> > > to
> > >
> > > <xsl:template match="row">
> > > <xsl:if test="id = '0432'">
> > > stuff
> > > </xsl:if>
> > > </xsl:template>
>
> Well, I fully trust the judgment of Jacek here...
>
> Depending on your favorite brand of XSLT engine, I'm quite sure different
> optimalizations will be applied upon stylesheet execution. XSLTC has been
> available long enough inside Xalan to finally start using it, or at least
> making its usage possible & optional. It will be up to the classloading
> gurus however to tackle this one.
>
> I must say I'm quite stumped finding out how you should rewrite/optimalize
> your stylesheet in order to fully utilize XSLTC: predicates in XSLT
> Patterns seem like a different beast to me than an xsl:if construct, and
> one can not be trusted to keep this kind of optimalization in mind while
> authoring a stylesheet.
>
> I'm quite sure this is not the intended behaviour of XSLTC, hopefully Jacek
> finds time to correct XSLTC on this.
>
> Anyway, another discussion which shows me XSLT has not yet proven to be a
> highly optimizable language, even though it has been created with
> side-effect-freeness in mind. And finally, something I learnt from Berin
> and other wise men on this list: one must not start with sourcecode
> optimalization targeting a specific runtime environment unless *all* other
> possibilities are exhausted. And XSLTC seems like a good possibility for
> the 'bad' (really?) XSLT performance in Cocoon.
>
> </Steven>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLT benchmarks: dbonerow
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
>
> Robert Koberg wrote:
>
> > You know... I wonder why you guys don't spend time on optimizing the XSL (I
> > know Steven Noels is). This is most probably the bottleneck you are
> > experiencing?? You guys are taking the path away from general adoption...
> >
> >
> > ----- Original Message -----
> > From: "Jacek Ambroziak" <ja...@yahoo.com>
> > To: <xa...@xml.apache.org>; <co...@xml.apache.org>
> > Cc: <st...@apache.org>
> > Sent: Wednesday, February 20, 2002 7:24 PM
> > Subject: XSLT benchmarks: dbonerow
> >
> >
>
> [...]
>
> > >
> > > I have rewritten XSL as follows:
> > >
> > > <xsl:template match="row[id = '0432']">
> > > stuff
> > > </xsl:template>
> > >
> > > to
> > >
> > > <xsl:template match="row">
> > > <xsl:if test="id = '0432'">
> > > stuff
> > > </xsl:if>
> > > </xsl:template>
> > >
>
> Well, I fully trust the judgment of Jacek here...
>
> Depending on your favorite brand of XSLT engine, I'm quite sure different
> optimalizations will be applied upon stylesheet execution. XSLTC has been
> available long enough inside Xalan to finally start using it, or at least making
> its usage possible & optional. It will be up to the classloading gurus however
> to tackle this one.
>
> I must say I'm quite stumped finding out how you should rewrite/optimalize your
> stylesheet in order to fully utilize XSLTC: predicates in XSLT Patterns seem
> like a different beast to me than an xsl:if construct, and one can not be
> trusted to keep this kind of optimalization in mind while authoring a
> stylesheet.
>
> I'm quite sure this is not the intended behaviour of XSLTC, hopefully Jacek
> finds time to correct XSLTC on this.
>
> Anyway, another discussion which shows me XSLT has not yet proven to be a highly
> optimizable language, even though it has been created with side-effect-freeness
> in mind. And finally, something I learnt from Berin and other wise men on this
> list: one must not start with sourcecode optimalization targeting a specific
> runtime environment unless *all* other possibilities are exhausted. And XSLTC
> seems like a good possibility for the 'bad' (really?) XSLT performance in
> Cocoon.
Which leads me to think: how hard/expensive would be for an XSLT
processor to 'optimize' algorithmically the XSLT stylesheet?
I mean: fast SQL implementations do this: transform the SQL in a
in-memory structure, then perform some algebraic analysis to obtain
*all* the possible ways to execute he same query (it's hard to formalize
it, but it's doable), then perform some statistical analysis on the
different 'strategies' in order to evaluate the potential algorithmic
cost of each one, then choose the cheapest one and compile that.
Now: XSLTC spends some time creating the translet, I'm pretty sure that
nobody would mind, in a server environment, at least, if XSLTC spent
even a second to find out the best strategy to compile the stylesheet.
Sure, for interpreted execution this might be too much of an overhead,
but for server side compiled execution (given the fact that stylesheets
rarely change in a production environment), the differences that Jacek
show are *huge* and could potentially lead to *incredible* performance
compared to other 'standard' solutions.
I think Scott is right saying that you can't go faster than something
when you are checking for everything in the stylesheet (compliance,
tracing, error cheching and so on) but who said this should be done at
runtime?
IMO, the best think would be to have an XSLT interpreter for your
development cycles (where compliance and low latency are most important)
and an XSLT compiler for production release (where runtime performance
and scalability are the issues and low latency is not).
Add the ability to 'algorithmically optimize' the sytlesheet before
compilation and I think that we have solved all our issues with XSLT
performance.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: XSLT benchmarks: dbonerow
Posted by "Jacek R. Ambroziak" <ja...@yahoo.com>.
The rewrite experiment only shows that there is a *serious bug*
in the compiler code AND that there is *hope* for much improved
performance of translets testing conditions in template patterns.
'dbonerow' helped focus our attention. There are other tests (eg. decoy)
which seem affected by the same bug. And then there are of course
many stylesheets written by our users :-)
The rewrite is of the form:
if (A && B) { ... } --> if (A) { if (B) { ... }}
If the second version is 300 times faster, then we've got
something interesting going on here :-)
--Jacek
On Thursday 21 February 2002 04:22 am, Steven Noels wrote:
> Robert Koberg wrote:
> > You know... I wonder why you guys don't spend time on optimizing the XSL
> > (I know Steven Noels is). This is most probably the bottleneck you are
> > experiencing?? You guys are taking the path away from general adoption...
> >
>
>
> > > I have rewritten XSL as follows:
> > >
> > > <xsl:template match="row[id = '0432']">
> > > stuff
> > > </xsl:template>
> > >
> > > to
> > >
> > > <xsl:template match="row">
> > > <xsl:if test="id = '0432'">
> > > stuff
> > > </xsl:if>
> > > </xsl:template>
>
> Well, I fully trust the judgment of Jacek here...
>
> Depending on your favorite brand of XSLT engine, I'm quite sure different
> optimalizations will be applied upon stylesheet execution. XSLTC has been
> available long enough inside Xalan to finally start using it, or at least
> making its usage possible & optional. It will be up to the classloading
> gurus however to tackle this one.
>
> I must say I'm quite stumped finding out how you should rewrite/optimalize
> your stylesheet in order to fully utilize XSLTC: predicates in XSLT
> Patterns seem like a different beast to me than an xsl:if construct, and
> one can not be trusted to keep this kind of optimalization in mind while
> authoring a stylesheet.
>
> I'm quite sure this is not the intended behaviour of XSLTC, hopefully Jacek
> finds time to correct XSLTC on this.
>
> Anyway, another discussion which shows me XSLT has not yet proven to be a
> highly optimizable language, even though it has been created with
> side-effect-freeness in mind. And finally, something I learnt from Berin
> and other wise men on this list: one must not start with sourcecode
> optimalization targeting a specific runtime environment unless *all* other
> possibilities are exhausted. And XSLTC seems like a good possibility for
> the 'bad' (really?) XSLT performance in Cocoon.
>
> </Steven>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
RE: XSLT benchmarks: dbonerow
Posted by Steven Noels <st...@outerthought.org>.
Robert Koberg wrote:
> You know... I wonder why you guys don't spend time on optimizing the XSL (I
> know Steven Noels is). This is most probably the bottleneck you are
> experiencing?? You guys are taking the path away from general adoption...
>
>
> ----- Original Message -----
> From: "Jacek Ambroziak" <ja...@yahoo.com>
> To: <xa...@xml.apache.org>; <co...@xml.apache.org>
> Cc: <st...@apache.org>
> Sent: Wednesday, February 20, 2002 7:24 PM
> Subject: XSLT benchmarks: dbonerow
>
>
[...]
> >
> > I have rewritten XSL as follows:
> >
> > <xsl:template match="row[id = '0432']">
> > stuff
> > </xsl:template>
> >
> > to
> >
> > <xsl:template match="row">
> > <xsl:if test="id = '0432'">
> > stuff
> > </xsl:if>
> > </xsl:template>
> >
Well, I fully trust the judgment of Jacek here...
Depending on your favorite brand of XSLT engine, I'm quite sure different
optimalizations will be applied upon stylesheet execution. XSLTC has been
available long enough inside Xalan to finally start using it, or at least making
its usage possible & optional. It will be up to the classloading gurus however
to tackle this one.
I must say I'm quite stumped finding out how you should rewrite/optimalize your
stylesheet in order to fully utilize XSLTC: predicates in XSLT Patterns seem
like a different beast to me than an xsl:if construct, and one can not be
trusted to keep this kind of optimalization in mind while authoring a
stylesheet.
I'm quite sure this is not the intended behaviour of XSLTC, hopefully Jacek
finds time to correct XSLTC on this.
Anyway, another discussion which shows me XSLT has not yet proven to be a highly
optimizable language, even though it has been created with side-effect-freeness
in mind. And finally, something I learnt from Berin and other wise men on this
list: one must not start with sourcecode optimalization targeting a specific
runtime environment unless *all* other possibilities are exhausted. And XSLTC
seems like a good possibility for the 'bad' (really?) XSLT performance in
Cocoon.
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: XSLT benchmarks: dbonerow
Posted by Robert Koberg <ro...@koberg.com>.
You know... I wonder why you guys don't spend time on optimizing the XSL (I
know Steven Noels is). This is most probably the bottleneck you are
experiencing?? You guys are taking the path away from general adoption...
----- Original Message -----
From: "Jacek Ambroziak" <ja...@yahoo.com>
To: <xa...@xml.apache.org>; <co...@xml.apache.org>
Cc: <st...@apache.org>
Sent: Wednesday, February 20, 2002 7:24 PM
Subject: XSLT benchmarks: dbonerow
> Setting the stage:
>
> Today's XSLTC translets perform abysmally on the
> 'dbonerow' benchmark.
> The XML document is a set of 10^4 records and the
> stylesheet contains
> one template designed to match (and process) one of
> the records;
> XSLT essentially performs a search by matching.
>
> On my machine 10 iterations of 'dbonerow' take
> Saxon/XT/Xalan approx. 20 sec
> compared to 7 times longer for a translet. The time
> loss is so huge that
> XSLTC looses all gains from other tests and comes
> last.
>
> Towards a better tomorrow:
>
> I have rewritten XSL as follows:
>
> <xsl:template match="row[id = '0432']">
> stuff
> </xsl:template>
>
> to
>
> <xsl:template match="row">
> <xsl:if test="id = '0432'">
> stuff
> </xsl:if>
> </xsl:template>
>
> Now Saxon/XT/Xalan still need around 20 seconds
> (although they too prefer
> the second variant). A translet, however, takes only
> 0.5 second
> (or even 68msec w/o printing output). Used to be 7
> times slower
> -- now is 40 times faster. This is shocking!
>
> with this rewrite the magic numbers in my environment
> are:
>
> XSLTC 780
> XT 482
> Saxon 304
> XalanJ 207
>
> Obviously, the compiler is doing something VERY WRONG
> for this test
> (and presumably for 'patterns', 'decoy', etc.)
>
> So there is hope.
>
> Fixing the problem will not be easy; not only I've
> forgotten many
> implementation details, but the code has changed since
> I last worked on it
> (not always to my liking :-( )
>
> --Jacek
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org