You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Greg Weinger <gw...@itmedicine.net> on 2002/04/04 22:27:28 UTC
[SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> So, expect my comments soon.
It's been a while, so I wanted to recap previous discussions from the
archives. (No pressure, Stefano, I'm just trying to do some of the
legwork :)
Stefano's last word on the subject was here
(http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg12420.html) To
summarize, Vadim proposed his Multiplexer idea as a better solution than
pipe-aware selection. Stefano agreed, thought the idea more elegant,
but asked for a recap of the issues, and a specific proposal from Vadim.
The multiplexer came out of a larger proposal from Vadim, (I can't find
it in the archive) in which serializers could be given destinations,
which sparked the Sources and Drains thread. The key questions there I
felt were, "should we allow a component that triggers pipelines that
don't return data?" and "What kinds of piplines should be allowed?"
IMO, the multiplexer idea stands on its own, without the larger
proposal. As Carsten pointed out, you can achieve a non-returning
pipeline by side-effect: what's the difference between a pipeline that
doesn't return any events and an explicit drain? If adding explicit
drains reduces architectural clarity, it should be avoided.
To be honest, I haven't looked at Daniel's new selection code, but from
the description, given its use of DOM and additional pipeline
generation, I still think Vadim's Multiplexer proposal comes out ahead
in terms of elegance and performance. Plus it has more use cases than
simple pipeline dispatching.
Open questions: does Schecoon and/or the recent labels discussion change
any of this?
Excerpted below is Vadim's idea, from
(http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg11409.html )
<excerpt>
> I have another one, it provides different functionality but it
features
> similar approach. As I don't have a name for this (multiplexer?), here
> is the diagram:
>
> - pipeline1 -
> / \
> request -> A -> X - pipeline2 - X -> C -> response
> \ /
> - pipelineN -
>
> Explanation:
> 1. Request goes in
> 2. Pipeline is being constructed from A, X, C
> 3. SAX events passed from the A to X, where they are dispatched (same
as
> separator) to several other pipelines
> 4. SAX events passed from these events reassembled into the one SAX
> stream by the same instance of X component 5. Result passed down the
> original pipeline to the C 6. C spits out the response
>
> Don't answer "hey, you can do this with content aggregator" - it is
not
> true, this is a different thing.
</excerpt>
--
Gregory Weinger To work is not merely to produce,
it is to give value to time.
[gweinger@itmedicine.net] Eugene Delacroix
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was:
[Contribution]Pipe-aware selection)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:44 pm +0200 11/4/02, Ulrich Mayring wrote:
>Jeremy Quinn wrote:
>>
>> During the 'put' phase in <slash-edit/>, the instance, having been
>> assembled from the Request by an XSLT, it is then processed with the
>> generated Validator XSLT.
>>
>> Next an 'adaptor' XSLT checks there were no Validation errors before
>> wrapping the instance in a <source:write/> tag so that the
>> SourceWritingTransformer (later in the pipeline) can output it to the
>> Source.
>>
>> Is it these tiny, one-job adaptor XSLTs and the logic they perform causing
>> you these problems, or is it the whole concept of incrementally adapting
>> content in the pipeline?
>
>It seems to be a fairly procedural approach and, while I have not seen
>what these XSLT stylesheets do exactly, they appear to work in a fairly
>deterministic way.
Have a look ;)
Keep in mind it is work in progress ....
>XSLT is not ideal for procedural algorithms, but at
>the end of the day it's just another language. There is a tradeoff
>between doing things in a less-then-ideal, but available language
>compared to an ideal, but less-than-available language. If you use XSLT
>just for two internal things, the tradeoff may be on your side, if your
>users start to write their own XSLT stylesheets to configure the
>process, then perhaps the tradeoff falls on the other side. YMMV :)
I am gradually separating out the XSLTs that are 'inherent' ie. don't need
to be touched because they are part of the way slash-edit works, and those
that the 'user' legitimately needs to modify for themselves.
Any contracts in the 'inherent' XSLT can be firmed up, in terms of the
<editor/> DTD (the way it 'carries' the Instance, config and reports
errors), and the messages received from the SiteMap. These components can
be implemented in Java as and when necessary.
At the moment, the 'user' has to modify certain files to:
(1) Handle their own DTD and namespaces
the XSLT to convert the Request data into the Instance
the XSLT for converting the Instance into a Form
the Schematron document for validating their Instance
(2) Provide their own style
The next step could be to turn both XSLT aspects of (1) into a set of
generic Transformations that share a config file for both operations, then
potentially this could be implemented in Java.
Or instead of implementing any of this XSLT as Java, we could treat it like
we treat logicsheets, compile them into the cocoon.jar and access them as
resources.
Thanks for your interest
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution]Pipe-aware
selection)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> During the 'put' phase in <slash-edit/>, the instance, having been
> assembled from the Request by an XSLT, it is then processed with the
> generated Validator XSLT.
>
> Next an 'adaptor' XSLT checks there were no Validation errors before
> wrapping the instance in a <source:write/> tag so that the
> SourceWritingTransformer (later in the pipeline) can output it to the
> Source.
>
> Is it these tiny, one-job adaptor XSLTs and the logic they perform causing
> you these problems, or is it the whole concept of incrementally adapting
> content in the pipeline?
It seems to be a fairly procedural approach and, while I have not seen
what these XSLT stylesheets do exactly, they appear to work in a fairly
deterministic way. XSLT is not ideal for procedural algorithms, but at
the end of the day it's just another language. There is a tradeoff
between doing things in a less-then-ideal, but available language
compared to an ideal, but less-than-available language. If you use XSLT
just for two internal things, the tradeoff may be on your side, if your
users start to write their own XSLT stylesheets to configure the
process, then perhaps the tradeoff falls on the other side. YMMV :)
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution]
Pipe-aware selection)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 4:21 pm +0200 10/4/02, Ulrich Mayring wrote:
>>Stefano Mazzocchi wrote:
>> In short: stylesheets's declarativeness was designed to make their
>> contracts less solid ("if this template matches, run it, otherwise do
>> nothing and don't even signal it"). It's very easy to have 'dead parts'
>> of your declarative code.
>>
>> This is a *feature* when it comes to 'what-if' scenarios but Jeremy has
>> been using them in a procedural case and this, IMO, sacrifices contract
>> solidity, expecially in a multi-authored environment like this one.
>
>Yes, I understand what you mean here. It's unproductive and error-prone
>to model procedural scenarios with declarative algorithms. Either change
>the scenario to become declarative or change the modelling language to
>become procedural - any mixture of the two will not work.
I obviously find this pronouncement a bit disturbing .....
The general idea for making (content-editing) pipelines that have a 'drain'
to output modified content via a WriteableSource has been in development
(on and off) for several months now. It has come out of discussions on
cocoon-dev and privately, with numerous collaborators.
Is the problem with the whole concept, or merely my implementation of it?
For example:
During the 'put' phase in <slash-edit/>, the instance, having been
assembled from the Request by an XSLT, it is then processed with the
generated Validator XSLT.
Next an 'adaptor' XSLT checks there were no Validation errors before
wrapping the instance in a <source:write/> tag so that the
SourceWritingTransformer (later in the pipeline) can output it to the
Source.
Is it these tiny, one-job adaptor XSLTs and the logic they perform causing
you these problems, or is it the whole concept of incrementally adapting
content in the pipeline?
Thanks for any assistance.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Ulrich Mayring <ul...@denic.de>.
Stefano Mazzocchi wrote:
>
> Ulrich Mayring wrote:
>
> > Could you explain where XSLT lacks solidity?
>
> First: it's a pain to validate because it's an heavy user of namespaces.
Sorry, I don't understand this one. Do you want to validate XSLT
stylesheets themselves? And if yes: don't they contain just the XSL
namespace?
> Second: declarativity hides the pipeline flow: you might change a
> template apply-template statement, still have a valid stylesheet, but
> change the overall behavior of the pipeline without noticing.
True.
> Third: stylesheets don't exhibit explicit in/out contracts: it's very
> hard to understand (even worse to validate!) if two stylesheets have a
> compatible behavior on a given input.
Yes, that's a function of declarative processing.
> In short: stylesheets's declarativeness was designed to make their
> contracts less solid ("if this template matches, run it, otherwise do
> nothing and don't even signal it"). It's very easy to have 'dead parts'
> of your declarative code.
>
> This is a *feature* when it comes to 'what-if' scenarios but Jeremy has
> been using them in a procedural case and this, IMO, sacrifices contract
> solidity, expecially in a multi-authored environment like this one.
Yes, I understand what you mean here. It's unproductive and error-prone
to model procedural scenarios with declarative algorithms. Either change
the scenario to become declarative or change the modelling language to
become procedural - any mixture of the two will not work.
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution]
Pipe-aware selection)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 2:35 pm +0200 10/4/02, Stefano Mazzocchi wrote:
>Ulrich Mayring wrote:
>
>> Could you explain where XSLT lacks solidity?
<snip/>
>In short: stylesheets's declarativeness was designed to make their
>contracts less solid ("if this template matches, run it, otherwise do
>nothing and don't even signal it"). It's very easy to have 'dead parts'
>of your declarative code.
Absolutely true
>This is a *feature* when it comes to 'what-if' scenarios but Jeremy has
>been using them in a procedural case and this, IMO, sacrifices contract
>solidity, expecially in a multi-authored environment like this one.
>
>HOpe this helps.
XSLT is just a language ....
A very easily adaptable one in the Cocoon environment, hence the ease with
which I can experiment with different ideas and switch things around.
A problem in a production environment however as you point out.
My hope with the <slash-edit/> experiment is that a clean identification
and separation of concerns can be found, and applied to XSLT as to the
other components; the XSLT language could be used by more than just the
'style' group.
As contracts solidify, decisions can be made about which XSLT implemented
contracts it is worth converting to Java Transformers what adapt the
pipeline according to their role.
It's heretical stuff, I know ;)
Thanks for the interest
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ulrich Mayring wrote:
> Could you explain where XSLT lacks solidity?
First: it's a pain to validate because it's an heavy user of namespaces.
Second: declarativity hides the pipeline flow: you might change a
template apply-template statement, still have a valid stylesheet, but
change the overall behavior of the pipeline without noticing.
Third: stylesheets don't exhibit explicit in/out contracts: it's very
hard to understand (even worse to validate!) if two stylesheets have a
compatible behavior on a given input.
In short: stylesheets's declarativeness was designed to make their
contracts less solid ("if this template matches, run it, otherwise do
nothing and don't even signal it"). It's very easy to have 'dead parts'
of your declarative code.
This is a *feature* when it comes to 'what-if' scenarios but Jeremy has
been using them in a procedural case and this, IMO, sacrifices contract
solidity, expecially in a multi-authored environment like this one.
HOpe this helps.
--
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: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Ulrich Mayring <ul...@denic.de>.
Stefano Mazzocchi wrote:
>
> Keep in mind that SoC works only if the contract between concern islands
> is solid.
>
> If I were to bet on the solidity of something, XSLT would not exactly be
> my first item in the list.
Could you explain where XSLT lacks solidity?
thanks in advance,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> I believe that it is a better SoC to let the
> sitemap handle control structure and data flow and let the transformers
> transform single documents.
Absolutely agreed.
> > Furthermore, is there REALLY a difference between these two pipelines:
> >
> > - pipeline1 -
> > / \
> > request -> A -> X - pipeline2 - X -> C -> response
> > \ /
> > - pipelineN -
> >
> >
> > request -> A -> P1 -> P2 -> P3 -> C -> response
> >
> > (where Pn are a group of Transformations/Actions etc.)
> >
> > Apart from how you would arrange them differently in the Sitemap, what is
> > the real need to have parallel processes?
> I assume that the above example uses a "multiplexer" that can choose sub
> streams from the input stream. You can achieve the same functionality with
> booth methods, but in the second example P1, P2 and P3 must "know" about
> each other. Consider an input document like:
>
> <input>
> <a> ... </a>
> <b> ... </b>
> <c> ... </c>
> </input>
>
> with the multiplexer you can write general "a"-handling, "b"-handling and so
> on, sub pipelines that can be reused in other contexts. For the second
> construction, the transformer P1 must know about the root node "input" and
> that "b" and "c" are supposed to be copied to the output, and similarly for
> P2 and P3.
>
> To summarize: booth pipe-aware selection and multiplexers can be implemented
> in terms of xslt, but it distributes the control structure to booth the
> sitemap and the stylesheets, and it implies that the stylesheets must know
> about their contexts, which makes them harder to reuse.
I agree.
Keep in mind that SoC works only if the contract between concern islands
is solid.
If I were to bet on the solidity of something, XSLT would not exactly be
my first item in the list.
--
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: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Jeremy Quinn wrote:
<snip/>
> Maybe I do not recognise the differences yet, but the examples
> you provided
> for how "pipe-aware selection" would work, are all possible without such a
> selector, please see the 'editor.xmap' in <slash-edit/>.
IIUC, you put a lot of control structure in XSLT. I have also used that kind
of constructions in a couple of applications. Yes you can do everything that
you can do with a pipe-aware selector that way, but IMHO it obscures the
control structure of your application, to understand the data flow and the
control structure of the application, one have to look booth in the sitemap
and in some xslt stylesheets. I believe that it is a better SoC to let the
sitemap handle control structure and data flow and let the transformers
transform single documents.
> Furthermore, is there REALLY a difference between these two pipelines:
>
> - pipeline1 -
> / \
> request -> A -> X - pipeline2 - X -> C -> response
> \ /
> - pipelineN -
>
>
> request -> A -> P1 -> P2 -> P3 -> C -> response
>
> (where Pn are a group of Transformations/Actions etc.)
>
> Apart from how you would arrange them differently in the Sitemap, what is
> the real need to have parallel processes?
I assume that the above example uses a "multiplexer" that can choose sub
streams from the input stream. You can achieve the same functionality with
booth methods, but in the second example P1, P2 and P3 must "know" about
each other. Consider an input document like:
<input>
<a> ... </a>
<b> ... </b>
<c> ... </c>
</input>
with the multiplexer you can write general "a"-handling, "b"-handling and so
on, sub pipelines that can be reused in other contexts. For the second
construction, the transformer P1 must know about the root node "input" and
that "b" and "c" are supposed to be copied to the output, and similarly for
P2 and P3.
To summarize: booth pipe-aware selection and multiplexers can be implemented
in terms of xslt, but it distributes the control structure to booth the
sitemap and the stylesheets, and it implies that the stylesheets must know
about their contexts, which makes them harder to reuse.
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution]
Pipe-aware selection)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 5:11 pm +0200 5/4/02, Daniel Fagerström wrote:
>> For sure we need more symmetry and more functionality in the pipelines.
>> If multiplexing and pipe-aware selection are the way to implement them
>> is yet to be understood.
>
>Agreed, it is definitly my, (and all the other raving "pipe-aware
>selection" fans out there ;) ) resposibility to provide examples on how
>elegantly you can construct webapps with the help of just a few extra
>sitemap components. I hope to be able to provide some example code and
>an RT quite soon. Until then some sceptisism seem like a sound strategy.
Maybe I do not recognise the differences yet, but the examples you provided
for how "pipe-aware selection" would work, are all possible without such a
selector, please see the 'editor.xmap' in <slash-edit/>.
Furthermore, is there REALLY a difference between these two pipelines:
- pipeline1 -
/ \
request -> A -> X - pipeline2 - X -> C -> response
\ /
- pipelineN -
request -> A -> P1 -> P2 -> P3 -> C -> response
(where Pn are a group of Transformations/Actions etc.)
Apart from how you would arrange them differently in the Sitemap, what is
the real need to have parallel processes?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@vizzavi.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerström wrote:
> > For sure we need more symmetry and more functionality in the pipelines.
> > If multiplexing and pipe-aware selection are the way to implement them
> > is yet to be understood.
>
> Agreed, it is definitly my, (and all the other raving "pipe-aware
> selection" fans out there ;) ) resposibility to provide examples on how
> elegantly you can construct webapps with the help of just a few extra
> sitemap components. I hope to be able to provide some example code and
> an RT quite soon. Until then some sceptisism seem like a sound strategy.
Thanks. It's nice to see my unpopular metodology against FS appreciated
:)
> >>I know that there have been a lot of concern about that a DOM-based
> >>pipe-aware selection mechanism would be a performance bottleneck, but:
> <snip/>
> > Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
> > by implementations because a community can always make it better.
>
> Good, I know that you have said so before, but it is anyway a relief to
> hear you saying that in this particular context.
You will never find me concerned about implementations. My experience
tells me that in a healthy communities, code gets improved automatically
by people that step on the plate and make it happen.
If they don't, well, than the code was simply good enough :)
This is the only 'code metric' that can possibly work.
> > I'm concerned by architecture design because I don't think that it's
> > equivally easy to progressively refine an architecture, expecially when
> > you need to provide back compatibility from each incremental step.
> > It's easy to add stuff, much easier than *not* to add stuff.
>
> Yes, these are _very_ important concerns, there might be a quite thin line
> between entropy death from due to added features and stagnation death due
> to fear of adding anything at all.
Oh, please, this is unfair: don't you think that 'stagnating death' is a
little too strong for a project like this? I don't think that my
resistence to FS has stopped this project from becoming one of the most
impressively growing that I know of. I don't venture to say the opposite
(I might not be part of this, just luck maybe) but at least I don't
think my anti-FS attitude has brought any harm.
> I can asure you that architectural and conceptual elegance is extremely
> important for me. I have struggled with how to handle webapps with a
> minimal number, efficient, and easy to understand concepts for months.
> That of course doesn't necesarily means that the results of my thinking
> is the best possible way of solving this issues, but at least I take
> these things seriously.
Daniel, please understand that I never wanted to insult you or imply any
incapacity from your side. No way, dude: I *always* start from the point
where *you* have to teach *me* something that I didn't get before.
This is why I love this community: there is always something to learn.
If I stopped all efforts that didn't go in directions I already knew,
how would I learn something? How would this project grow?
Believe me: my job is *not* to put you down with no reason, or
masquerading the thing with a 'your stuff in not elegant' enough.
My job is to challenge new architectural ideas and, I think you saw
this, challenge them pretty hard, with the intention to show their
streghts and, hopefully, outline their weaknesses *before* the users
find them but we have already released it and we have to support it for
years!
I sincerely hope you understand my point and my reasons.
> Anyway I'l try to finish some examples and I'l also repackage the pipe-aware
> selector code to a scratchpad contribution and put my hope on that some
> kind commiter will add it :) In that case I need a small, small addition
> to one of the support classes in the interpreted sitemap - please, please
> consider adding it ;)
I'm not against small changes to the interpreted sitemap, I'm more
concerned by the 'multipaths' this creates: some people will use
pipe-aware selection and some might use another solution.
Then we find out that one of the two is weaker, but we still have to
support 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: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Ivelin Ivanov <iv...@apache.org>.
Here is the snippet in question:
> What if we implement only the subset of XPath which satisfies
> 90% of the
> needs and can work with a SAX stream.
> Many times the test would be like:
> 1) Does element A exist, or
> 2) Does element A have value b, or
> 3) Does element A appear n times, or
> 4) similar tests against attributes
5) Combinations of all the above methods, e.g.: does element A exits, then
check if element B has value b.
----- Original Message -----
From: "Daniel Fagerstrom" <da...@swipnet.se>
To: <co...@xml.apache.org>
Sent: Monday, April 08, 2002 4:20 PM
Subject: RE: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
> Ivelin Ivanov wrote:
> > Without taking any side in this argument, simply because I don't
> > have enough
> > real world experience with pipe-aware selectors, I would like to share
an
> > RT.
> >
> > If xpath selector is chosen to make it in Cocoon, it can be implemented
> > very efficiently.
> > Those who have followed the discussion remember Konstantin and I
proposing
> > an XPath subset which
> > can cover majority of the use cases.
> I didn't find your mail about the XPath subset in the archive could you
> please send a pointer?
>
> > Indeed there is a readily available library of good quality which can be
> > utilized.
> > It is the Digester tool from Apache Jakarta Commons.
> > http://jakarta.apache.org/commons/digester.html
> >
> > If I am not mistaken, for a sitemap like the following, Digester can be
> > initialized with all the selector when tests.
> > Then it can cash the sax stream until any of the tests is satisfied, at
> > which point, the cached sax stream can be unleashed to the next SAX
> > consumer.
> I got the impression that Digester parses the sax input and applies rules
on
> it that typically creates an object hierarchy, but I didn't found any
> methods for creating sax output, did you? Or do you suggest an
> implementation where the input sax is sent booth to Digester for testing
and
> to a cache?
>
> /Daniel Fagerstrom
>
>
>
> ---------------------------------------------------------------------
> 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
RE: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Daniel Fagerstrom <da...@swipnet.se>.
Ivelin Ivanov wrote:
> Without taking any side in this argument, simply because I don't
> have enough
> real world experience with pipe-aware selectors, I would like to share an
> RT.
>
> If xpath selector is chosen to make it in Cocoon, it can be implemented
> very efficiently.
> Those who have followed the discussion remember Konstantin and I proposing
> an XPath subset which
> can cover majority of the use cases.
I didn't find your mail about the XPath subset in the archive could you
please send a pointer?
> Indeed there is a readily available library of good quality which can be
> utilized.
> It is the Digester tool from Apache Jakarta Commons.
> http://jakarta.apache.org/commons/digester.html
>
> If I am not mistaken, for a sitemap like the following, Digester can be
> initialized with all the selector when tests.
> Then it can cash the sax stream until any of the tests is satisfied, at
> which point, the cached sax stream can be unleashed to the next SAX
> consumer.
I got the impression that Digester parses the sax input and applies rules on
it that typically creates an object hierarchy, but I didn't found any
methods for creating sax output, did you? Or do you suggest an
implementation where the input sax is sent booth to Digester for testing and
to a cache?
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Ivelin Ivanov <iv...@apache.org>.
Without taking any side in this argument, simply because I don't have enough
real world experience with pipe-aware selectors, I would like to share an
RT.
If xpath selector is chosen to make it in Cocoon, it can be implemented
very efficiently.
Those who have followed the discussion remember Konstantin and I proposing
an XPath subset which
can cover majority of the use cases.
Indeed there is a readily available library of good quality which can be
utilized.
It is the Digester tool from Apache Jakarta Commons.
http://jakarta.apache.org/commons/digester.html
If I am not mistaken, for a sitemap like the following, Digester can be
initialized with all the selector when tests.
Then it can cash the sax stream until any of the tests is satisfied, at
which point, the cached sax stream can be unleashed to the next SAX
consumer.
<map:match pattern="userDataInsert.xml">
<map:generate type="stream"/>
<map:transform src="userData.xsd" type="validator"/>
<map:select type="xpath">
<map:when test="/*/@fatal-error">
<map:transform src="structureErrors.xsl"/>
</map:when>
<map:when test="/*/@field-error">
<map:transform src="userDataForm.xsl"/>
</map:when>
<map:otherwise>
<map:transform type="file-writer" dest="userData.xml"/>
<map:select type="xpath">
<map:when test="/result/file-writen='true'">
<map:transform src="reportInsertResult.xsl"/>
</map:when>
<map:otherwise>
<map:transform src="reportInsertError.xsl"/>
</map:otherwise>
</map:select>
</map:otherwise>
</map:select>
<map:serialize/>
</map:match>
Here is a snipped of code from Struts' ActionServlet which demonstrates how
Digester is initialized:
/**
* Construct and return a digester that uses the new configuration
* file format.
*/
protected Digester initDigester(int detail) {
// Initialize a new Digester instance
Digester digester = new Digester();
digester.push(this);
digester.setDebug(detail);
digester.setValidating(validating);
// Register our local copy of the DTDs that we can find
for (int i = 0; i < registrations.length; i += 2) {
URL url = this.getClass().getResource(registrations[i+1]);
if (url != null)
digester.register(registrations[i], url.toString());
}
// Configure the processing rules
digester.addObjectCreate("struts-config/data-sources/data-source",
"org.apache.struts.util.GenericDataSource",
"type");
digester.addSetProperties("struts-config/data-sources/data-source");
digester.addRule("struts-config/data-sources/data-source",
new AddDataSourceRule(digester));
digester.addSetProperty
("struts-config/data-sources/data-source/set-property",
"property", "value");
digester.addObjectCreate("struts-config/action-mappings/action",
mappingClass, "className");
digester.addSetProperties("struts-config/action-mappings/action");
digester.addSetNext("struts-config/action-mappings/action",
"addMapping",
"org.apache.struts.action.ActionMapping");
digester.addSetProperty
("struts-config/action-mappings/action/set-property",
"property", "value");
digester.addObjectCreate
("struts-config/action-mappings/action/forward",
forwardClass, "className");
digester.addSetProperties
("struts-config/action-mappings/action/forward");
digester.addSetNext("struts-config/action-mappings/action/forward",
"addForward",
"org.apache.struts.action.ActionForward");
digester.addSetProperty
("struts-config/action-mappings/action/forward/set-property",
"property", "value");
digester.addObjectCreate("struts-config/form-beans/form-bean",
formBeanClass, "className");
digester.addSetProperties("struts-config/form-beans/form-bean");
digester.addSetNext("struts-config/form-beans/form-bean",
"addFormBean",
"org.apache.struts.action.ActionFormBean");
digester.addSetProperty
("struts-config/form-beans/form-bean/set-property",
"property", "value");
digester.addObjectCreate("struts-config/global-forwards/forward",
forwardClass, "className");
digester.addSetProperties("struts-config/global-forwards/forward");
digester.addSetNext("struts-config/global-forwards/forward",
"addForward",
"org.apache.struts.action.ActionForward");
digester.addSetProperty
("struts-config/global-forwards/forward/set-property",
"property", "value");
return (digester);
}
----- Original Message -----
From: "Daniel Fagerström" <da...@nada.kth.se>
To: <co...@xml.apache.org>
Sent: Friday, April 05, 2002 9:11 AM
Subject: Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Stefano Mazzocchi wrote:
> Daniel Fagerström wrote:
<snip/>
> We all want this. But I *DO*NOT* want to start tweaking the sitemap
> elegance before the flowmaps are implemented.
>
> My personal perception is that we are using the 'hammer antipattern'
> here: the sitemap is the hammer, and everything looks like a nail.
Or maybe Occam's razor: "one should not increase, beyond what is
necessary, the number of entities required to explain anything" ;)
<snip/>
> For sure we need more symmetry and more functionality in the pipelines.
> If multiplexing and pipe-aware selection are the way to implement them
> is yet to be understood.
Agreed, it is definitly my, (and all the other raving "pipe-aware
selection" fans out there ;) ) resposibility to provide examples on how
elegantly you can construct webapps with the help of just a few extra
sitemap components. I hope to be able to provide some example code and
an RT quite soon. Until then some sceptisism seem like a sound strategy.
>>I know that there have been a lot of concern about that a DOM-based
>>pipe-aware selection mechanism would be a performance bottleneck, but:
<snip/>
> Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
> by implementations because a community can always make it better.
Good, I know that you have said so before, but it is anyway a relief to
hear you saying that in this particular context.
> I'm concerned by architecture design because I don't think that it's
> equivally easy to progressively refine an architecture, expecially when
> you need to provide back compatibility from each incremental step.
> It's easy to add stuff, much easier than *not* to add stuff.
Yes, these are _very_ important concerns, there might be a quite thin line
between entropy death from due to added features and stagnation death due
to fear of adding anything at all.
I can asure you that architectural and conceptual elegance is extremely
important for me. I have struggled with how to handle webapps with a
minimal number, efficient, and easy to understand concepts for months.
That of course doesn't necesarily means that the results of my thinking
is the best possible way of solving this issues, but at least I take
these things seriously.
Anyway I'l try to finish some examples and I'l also repackage the pipe-aware
selector code to a scratchpad contribution and put my hope on that some
kind commiter will add it :) In that case I need a small, small addition
to one of the support classes in the interpreted sitemap - please, please
consider adding it ;)
/Daniel Fagerstrom
---------------------------------------------------------------------
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
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Daniel Fagerström <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerström wrote:
<snip/>
> We all want this. But I *DO*NOT* want to start tweaking the sitemap
> elegance before the flowmaps are implemented.
>
> My personal perception is that we are using the 'hammer antipattern'
> here: the sitemap is the hammer, and everything looks like a nail.
Or maybe Occam's razor: "one should not increase, beyond what is
necessary, the number of entities required to explain anything" ;)
<snip/>
> For sure we need more symmetry and more functionality in the pipelines.
> If multiplexing and pipe-aware selection are the way to implement them
> is yet to be understood.
Agreed, it is definitly my, (and all the other raving "pipe-aware
selection" fans out there ;) ) resposibility to provide examples on how
elegantly you can construct webapps with the help of just a few extra
sitemap components. I hope to be able to provide some example code and
an RT quite soon. Until then some sceptisism seem like a sound strategy.
>>I know that there have been a lot of concern about that a DOM-based
>>pipe-aware selection mechanism would be a performance bottleneck, but:
<snip/>
> Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
> by implementations because a community can always make it better.
Good, I know that you have said so before, but it is anyway a relief to
hear you saying that in this particular context.
> I'm concerned by architecture design because I don't think that it's
> equivally easy to progressively refine an architecture, expecially when
> you need to provide back compatibility from each incremental step.
> It's easy to add stuff, much easier than *not* to add stuff.
Yes, these are _very_ important concerns, there might be a quite thin line
between entropy death from due to added features and stagnation death due
to fear of adding anything at all.
I can asure you that architectural and conceptual elegance is extremely
important for me. I have struggled with how to handle webapps with a
minimal number, efficient, and easy to understand concepts for months.
That of course doesn't necesarily means that the results of my thinking
is the best possible way of solving this issues, but at least I take
these things seriously.
Anyway I'l try to finish some examples and I'l also repackage the pipe-aware
selector code to a scratchpad contribution and put my hope on that some
kind commiter will add it :) In that case I need a small, small addition
to one of the support classes in the interpreted sitemap - please, please
consider adding it ;)
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [status & RT] design challenges
Posted by Ivelin Ivanov <iv...@apache.org>.
I dare to challange our sitemap gurus to make a comparative analisys of the
Jakarta Workflow engine and C2 sitemap.
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerström wrote:
>
> Greg Weinger wrote:
> <snip/>
>
> > To summarize, Vadim proposed his Multiplexer idea as a better solution than
> > pipe-aware selection. Stefano agreed, thought the idea more elegant,
> > but asked for a recap of the issues, and a specific proposal from Vadim.
>
> I'd love to have a Multiplexer component in Cocoon. I'd like Cocoon
> develop to the point where you can build webapps as easy and as elegant
> as you can build webpublishing today.
We all want this. But I *DO*NOT* want to start tweaking the sitemap
elegance before the flowmaps are implemented.
My personal perception is that we are using the 'hammer antipattern'
here: the sitemap is the hammer, and everything looks like a nail.
Pipe-aware selection triggers these thoughts in my mind.
> I belive that one important part
> in achieving this goal is to be able to do most of the things that you
> have to write special pupose actions for today, to reusable pipeline
> components. IMO a Multiplexer have an important role to fill in this
> scenario, and so has pipe-aware selection.
hmmm...
> A selector choose _one_ of several processing paths for the input
> stream, while IIUC a multiplexer (at least conceptually), make several
> copies of the input stream, put each copy in a xpath-based filter that
> takes out a part of the stream and send it to a sub-pipeline, and in the
> end the filtered and processed streams are recombined to one single
> stream. IMO these are to different concern ares and I can't see any
> advantages in combining it to one component.
I agree on this.
> Yes, I'm aware that you can
> do pipe-aware selection in a multiplexer by making the filter xpaths
> mutually exclusive, so that only one of the sub-pipes are used:
>
> <multiplex>
> <part xpath="a and not(b) and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and b and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and c and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and not(c) and d">
> <!-- sub pipe -->
> </part>
> </multiplex>
>
> I fail to find that particular usage of multiplexing elegant.
I guess it's hard to disagree here :)
> It also
> seem higly non-trivial to write a multiplexer component that is
> efficient in the above scenario. Negations in xpaths are somewhat tricky
> beasts: <retoric-question>how much of the input stream do you need to
> scan (and buffer) before you know that "not(//elem)" is
> true?</retoric-question>
Right.
> IIRC there were never any concrete design propopsals in the multiplexer
> discussion and there is an implementation (although with some rough
> edges) of a pipe-aware selector, IMHO that is a not completely neglible
> difference between the two proposals ;)
>
> <snip/>
> > To be honest, I haven't looked at Daniel's new selection code,
>
> Please take a look at it, it is not much code at all, it is quite
> straight forward and I even added a few cryptic comments and wrote a
> README-file to the code ;)
>
> > but from the description, given its use of DOM and additional pipeline
> > generation, I still think Vadim's Multiplexer proposal comes out ahead
> > in terms of elegance and performance. Plus it has more use cases than
> > simple pipeline dispatching.
>
> See above. IMHO it is not a question about multiplexing vs pipe-aware
> selection, we need booth.
For sure we need more symmetry and more functionality in the pipelines.
If multiplexing and pipe-aware selection are the way to implement them
is yet to be understood.
> I know that there have been a lot of concern about that a DOM-based
> pipe-aware selection mechanism would be a performance bottleneck, but:
> * Pipe-aware selection will not affect your performance if you don't use
> it.;)) The only extra cost in the selector mechanism is a test if the
> PipeAware interface is implemented of the selector.
> * The main use case is input handling, and input is typically quite
> small amount of data.
> * Input is often put in databases, or used as input for some business
> components in that context DOM-tree construction is a minor cost.
> * Schematron validation e.g., requires DOM-input anyhow.
> Of course there might be use cases for pipe-aware selection where a DOM
> based implementation would be a major performance bottleneck, but untill
> we have seen that it seem IMHO unnecessary to do lots of complicated
> optimizations.
>
> <rant>
> I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I
> really appriciate your work for exorcising DOM from web publishing, but
> I think webapps are somewhat different, and I have written quite a lot
> about in what way on the list. With a few exceptions (thank you Stefano
> and Ivelin) all response I get is: he have used the D-word, Thou shall
> never use DOM in Cocoon. ;)
> I don't remember who wrote that: "premature optimzation is the root of
> all evil".
> </rant>
Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
by implementations because a community can always make it better.
I'm concerned by architecture design because I don't think that it's
equivally easy to progressively refine an architecture, expecially when
you need to provide back compatibility from each incremental step.
It's easy to add stuff, much easier than *not* to add stuff.
--
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: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware
selection)
Posted by Ulrich Mayring <ul...@denic.de>.
Daniel Fagerström wrote:
>
> <rant>
> I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I
> really appriciate your work for exorcising DOM from web publishing, but
> I think webapps are somewhat different, and I have written quite a lot
> about in what way on the list. With a few exceptions (thank you Stefano
> and Ivelin) all response I get is: he have used the D-word, Thou shall
> never use DOM in Cocoon. ;)
> I don't remember who wrote that: "premature optimzation is the root of
> all evil".
> </rant>
Apparently even XSLTC uses some type of DOM (though not the W3C one) and
XSLTC is reported to be very fast. It even has a built-in multiplexer.
Here is more info:
http://xml.apache.org/xalan-j/xsltc/xsltc_dom.html
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Greg Weinger <gw...@itmedicine.net>.
> From: Daniel Fagerström [mailto:danielf@nada.kth.se]
<snip/>
> I'd love to have a Multiplexer component in Cocoon. I'd like Cocoon
> develop to the point where you can build webapps as easy and
> as elegant
> as you can build webpublishing today.
Right on!
> A selector choose _one_ of several processing paths for the input
> stream, while IIUC a multiplexer (at least conceptually),
> make several
> copies of the input stream, put each copy in a xpath-based
> filter that
> takes out a part of the stream and send it to a sub-pipeline,
> and in the
> end the filtered and processed streams are recombined to one single
> stream. IMO these are to different concern ares and I can't see any
> advantages in combining it to one component.
Don't know about those implementation details, but you're right,
multiplexing fulfills a different need, for which I aim to contribute my
own little monster soon, which unfortunately uses caching instead of
true event forwarding.
>Yes, I'm aware
> that you can
> do pipe-aware selection in a multiplexer by making the
> filter xpaths
> mutually exclusive, so that only one of the sub-pipes are used:
>
> <multiplex>
> <part xpath="a and not(b) and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and b and not(c) and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and c and not(d)">
> <!-- sub pipe -->
> </part>
> <part xpath="not(a) and not(b) and not(c) and d">
> <!-- sub pipe -->
> </part>
> </multiplex>
> I fail to find that particular usage of multiplexing elegant.
Doesn't exactly put the best face on it ;)
I agree that this use is a hack, but I was imagining more trivial cases:
<multiplex>
<part xpath="/output/noresults" src="cocoon:/noresultspage" />
<part xpath="/output/results" src="cocoon:/resultsview"/>
</multiplex>
Not so hideous anymore, is it?
> It also
> seem higly non-trivial to write a multiplexer component that is
> efficient in the above scenario. Negations in xpaths are
> somewhat tricky
> beasts: <retoric-question>how much of the input stream do you need to
> scan (and buffer) before you know that "not(//elem)" is
> true?</retoric-question>
Agreed.
> IIRC there were never any concrete design propopsals in the
> multiplexer
> discussion and there is an implementation (although with some rough
> edges) of a pipe-aware selector, IMHO that is a not
> completely neglible
> difference between the two proposals ;)
I know :/ That's why I was trying to stir the pot, and help any way I
can.
> <snip/>
> > To be honest, I haven't looked at Daniel's new selection code,
>
> Please take a look at it, it is not much code at all, it is quite
> straight forward and I even added a few cryptic comments and wrote a
> README-file to the code ;)
I will, I promise.
> <rant>
> I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I
> really appriciate your work for exorcising DOM from web
> publishing, but
> I think webapps are somewhat different, and I have written
> quite a lot
> about in what way on the list. With a few exceptions (thank
> you Stefano
> and Ivelin) all response I get is: he have used the D-word,
> Thou shall
> never use DOM in Cocoon. ;)
> I don't remember who wrote that: "premature optimzation is
> the root of
> all evil".
> </rant>
Rant well taken :) Thank you all for opening my eyes.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Posted by Daniel Fagerström <da...@nada.kth.se>.
Greg Weinger wrote:
<snip/>
> To summarize, Vadim proposed his Multiplexer idea as a better solution than
> pipe-aware selection. Stefano agreed, thought the idea more elegant,
> but asked for a recap of the issues, and a specific proposal from Vadim.
I'd love to have a Multiplexer component in Cocoon. I'd like Cocoon
develop to the point where you can build webapps as easy and as elegant
as you can build webpublishing today. I belive that one important part
in achieving this goal is to be able to do most of the things that you
have to write special pupose actions for today, to reusable pipeline
components. IMO a Multiplexer have an important role to fill in this
scenario, and so has pipe-aware selection.
A selector choose _one_ of several processing paths for the input
stream, while IIUC a multiplexer (at least conceptually), make several
copies of the input stream, put each copy in a xpath-based filter that
takes out a part of the stream and send it to a sub-pipeline, and in the
end the filtered and processed streams are recombined to one single
stream. IMO these are to different concern ares and I can't see any
advantages in combining it to one component. Yes, I'm aware that you can
do pipe-aware selection in a multiplexer by making the filter xpaths
mutually exclusive, so that only one of the sub-pipes are used:
<multiplex>
<part xpath="a and not(b) and not(c) and not(d)">
<!-- sub pipe -->
</part>
<part xpath="not(a) and b and not(c) and not(d)">
<!-- sub pipe -->
</part>
<part xpath="not(a) and not(b) and c and not(d)">
<!-- sub pipe -->
</part>
<part xpath="not(a) and not(b) and not(c) and d">
<!-- sub pipe -->
</part>
</multiplex>
I fail to find that particular usage of multiplexing elegant. It also
seem higly non-trivial to write a multiplexer component that is
efficient in the above scenario. Negations in xpaths are somewhat tricky
beasts: <retoric-question>how much of the input stream do you need to
scan (and buffer) before you know that "not(//elem)" is
true?</retoric-question>
IIRC there were never any concrete design propopsals in the multiplexer
discussion and there is an implementation (although with some rough
edges) of a pipe-aware selector, IMHO that is a not completely neglible
difference between the two proposals ;)
<snip/>
> To be honest, I haven't looked at Daniel's new selection code,
Please take a look at it, it is not much code at all, it is quite
straight forward and I even added a few cryptic comments and wrote a
README-file to the code ;)
> but from the description, given its use of DOM and additional pipeline
> generation, I still think Vadim's Multiplexer proposal comes out ahead
> in terms of elegance and performance. Plus it has more use cases than
> simple pipeline dispatching.
See above. IMHO it is not a question about multiplexing vs pipe-aware
selection, we need booth.
I know that there have been a lot of concern about that a DOM-based
pipe-aware selection mechanism would be a performance bottleneck, but:
* Pipe-aware selection will not affect your performance if you don't use
it.;)) The only extra cost in the selector mechanism is a test if the
PipeAware interface is implemented of the selector.
* The main use case is input handling, and input is typically quite
small amount of data.
* Input is often put in databases, or used as input for some business
components in that context DOM-tree construction is a minor cost.
* Schematron validation e.g., requires DOM-input anyhow.
Of course there might be use cases for pipe-aware selection where a DOM
based implementation would be a major performance bottleneck, but untill
we have seen that it seem IMHO unnecessary to do lots of complicated
optimizations.
<rant>
I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I
really appriciate your work for exorcising DOM from web publishing, but
I think webapps are somewhat different, and I have written quite a lot
about in what way on the list. With a few exceptions (thank you Stefano
and Ivelin) all response I get is: he have used the D-word, Thou shall
never use DOM in Cocoon. ;)
I don't remember who wrote that: "premature optimzation is the root of
all evil".
</rant>
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org