cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Pipeline conditional model
Date Thu, 01 Jun 2000 17:25:18 GMT wrote:
> Stefano Mazzocchi wrote:
> >> Looking at it from a drawing lines between boxes perspective, a more
> >> straightforward approach is to put the conditions on the lines.  The
> >> XML equivalent would be:
> >>
> >>    <serializer type="wap" when="response gt 1.5KB" />
> >>    <serializer type="xml" when="response le 1.5KB" />
> >
> >Good suggestion.
> >
> >> For more complex cases, you can factor out the computation of the
> boolean
> >> expression into a separate XML structure, and only allow reference of
> the
> >> result here.  Similar to <available> in Ant.
> >
> >Can you make an example?
> Sure.  Let me start with a bad (in the sense that does not present the
> proposal in the most flattering light) example.  This is from your original
> mailing on the subject:
>   <process uri="*">
>    <if test="user belongs-to allowed-users"/>
>     <generator type="parser" src:local="*"/>
>     <if test="browser supports wap">
>      <filter type="xslt" srl:local="stylesheet/2wml.xsl"/>
>      <if test="response bigger-than 1.5Kb">
>       <serializer type="splitted-wap"/>
>      </if>
>      <else>
>       <serializer type="xml"/>
>      </else>
>     </if>
>     <else-if test="browser wants pdf"/>
>      <filter type="xslt" srl:local="stylesheet/2fo.xsl"/>
>      <serializer type="fo2pdf"/>
>     </else-if>
>     <else>
>      <filter type="xslt" src:local="stylesheet/2html.xsl">
>      <serializer type="html"/>
>     <else>
>    </if>
>    <else>
>     <resource name="Error Page"/>
>    </else>
>   </process>
> Here is a first pass at factoring out the conditions:
>   <states>
>     <condition name="legal"  test="user belongs-to allowed-users"/>
>     <condition name="tooBig" test="legal and response bigger-than 1.5Kb"/>
>     <condition name="wapOK"  test="legal and browser supports wap"/>
>     <condition name="pdfOK"  test="legal and browser wants pdf"/>
>     <condition name="sendErr"   test="not legal" />
>     <condition name="sendWAP"   test="wapOK and not tooBig"/>
>     <condition name="sendXML"   test="wapOK and tooBig"/>
>     <condition name="sendPDF"   test="wapOK and pdfOK"/>
>     <condition name="sendXSLT"  test="wapOK and not pdfOK"/>
>   <states>
>   <process uri="*">
>     <generator  when="legal"    type="parser" src:local="*"//>
>     <filter     when="wapOK"    type="xslt" srl:local="stylesheet/2wml.xsl"
>  />
>     <serializer when="sendWAP"  type="splitted-wap"/>
>     <serializer when="sendXML"  type="xml"/>
>     <filter     when="sendXSLT" type="xslt"
> srl:local="stylesheet/2fo.xsl"/>
>     <serializer when="sendPDF"  type="fo2pdf"/>
>     <filter     when="sendHTML" type="xslt"
> src:local="stylesheet/2html.xsl"/>
>     <serializer when="sendHTML" type="html"/>
>     <resource   when="sendErr"  name="Error Page"/>
>   </process>

Ok, got it.

Interesting enough, I played Sam's role in the creation of the JAMES
sitemap, advocating that flat pipelines are better than tree-like ones
(and implemented the same thing myself in Ant, even if that is kinda

But I changed my mind.

Now I feel like a "qubit", where the two state of minds are "quantumly


> First general observations:
> 1) From a Turing point of view, you lose no functionality.

> 2) I readily concede that the <if/> approach scales UP better - i.e., can
> handle flow patterns of arbitrary complexity better.  The above is an
> example of a moderately complex flow.  I would argue that if you are faced
> with anything more complicated than the above, you should hire a real
> programmer and implement a custom processor for your application in a
> "real" programming language.

> 3) I would argue that the "when=" approach scales DOWN better - simple
> conditions are handled in a more natural and intuitive fashion.

I'm still not sure of the impact on this over my girlfriend... I'd
better test it soon.
> 4) Then DTD for the "when=" approach is considerably simpler.

yes, simply because there is less marked up information (so you loose
validation power)
> 5) Conceptually, there still is a pipeline of processors, just diverters of
> arbitrary complexity which can be snapped on at any stage in the pipeline.

I'm concerned about the "necessity" of boolean logic inside the
attribute values to create these "state labels".
> 6) Both approaches are visually constructable.

> Now a few suggestions:
> 1) I still think people have their own predilections when it comes to which
> syntax they find more natural for expressions.  Allowing a language= on the
> condition statements would widen the appeal.  My vote for the default is
> JavaScript as it appeals to web designers and Java programmers alike.
> Unfortunately, JavaScript makes use of "<", ">", and "&" characters.
> Defining or picking a new language without these problems may be valuable.

That's the problem, you need such a thing. With an element-based
conditional model, you don't.
> 2) The name "states" is probably too computer-science-ish.  Valves,
> diverters, relays, or the like may be more fitting analogies.

I'm open to this, but it doesn't really matter.
> 3) I defined a bunch of random states in my example.  A common paradigm is
> mutually exclusive choices (the last 5 in my example).  Allowing a
> <choice><condition>*</choice> to appear any place a <condition>
can in the
> DTD, where every choice implicitly contains a "... and not any of the
> choices that preceded me" would simplify usage.

It appears to me that your solution removes complexity from the
pipeline, making it much more readable in complex conditional cases. But
I believe this is a "mirage": you are simply refactoring the complexity
someplace else, creating id-links between conditions and actions.

You are making procedural constructs declarative.

Which is something I welcome.

Normally, declarative languages are easier to read for non-programmers
because they mimic the "normal" human reasoning (which is _NOT_
procedural: yours might be because of your mindset). This is why XSLT
(or Prolog, for that matter) looks so "strange" to programmers.

Ant build files are fully declarative and they are much easier to write
and update compared to half-procedural/half-declarative makefiles.

In Ant we fought big time over the addition of conditional or interative
logic. Many proposed the addition of <if> or <for> elements, which would
have ruined the beauty of the declarative design.

But these are accademic questions, the real problem is: what is easier
to use? what syntax could allow your boss to maintain his family web
site with no help? [if you thought "this is not possible" go to "Jail"
and loose one turn :) there are CEOs on this list :)]

I have no answer and I like both ways.

Like I said I'm superimposed...


Oh gee... now its your turn to quantistically measure me to make my wave
function collapse on a definitive state :)

[sorry if you don't have any quantum physics background... it's your
fault, not mine :)]

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message