Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <601F6322AD71D5118D6C0003472515290660D087@sjmemexc1.stjude.org>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: Flow wishlist :)
Date: Tue, 26 Nov 2002 16:12:41 -0600
MIME-Version: 1.0
Content-Type: text/plain

Stefano, thanks for taking the time to reply in detail.  I'm going to snip
most of the discussion to keep this somewhat terse, but do have a couple of
further comments...

<small snip >

>> 
>> Well, yes mostly it is, but we have a requirement for very dynamic 
>> business logic and very dynamic flow logic.  As a result, I'd like to 
>> keep as much of the logic declarative (specifically, coded in XSLT) as 
>> possible.  We really need to mix and match business rules, business 
>> flow, presentation flow and presentation logic on the fly according to 
>> a pretty complex set of rules. Using XSLT allows us to stay much 
>> closer to a rules evaluation model and avoid what would otherwise be very
complex Java code.
>
> From what I read, when you talk about "XSLT" in this context, you are 
> talking about a declarative finite state machine approach that has 
> nothing to do with tree transformations. So I would suggest you stop 
> calling it XSLT or people might get confused about what you are proposing.

Well, no;  I'm proposing using XSLT to implement a parser that invokes
subsequent transforms....  The input tree is built up in the standard Cocoon
ways, and serves as the input for the decision tree.  The XSLT implements
the rules that run over this data to determine what subsequent transform to
invoke.  (One ends up transforming current context into new context plus new
transform.)

<big snip on historical intro/>

> But anyway, the concept goes down to earth: it is easier to write and 
> maintain a FSM or a command line application?
> 
> It depends, I hear you say. And you're right.
> 
> But it's definately easier to know people that can read say java or C or 
> python than can read prolog or lisp or scheme.

You forgot Haskell :-)

> Now, XSLT (which is an XML version of DSSSL, which was considered a 
> scheme dialect) changes the picture somewhat, even if everybody knows 
> how hard it is to find good XSLT-ists, expecially those being able to 
> read hardcore XSLT stylesheets (like James Clark's or Norman Walsh's, 
> for example).

I think we're pretty much in agreement.  The biggest issue I see is that
even though it's hard to find good functional programmers its probably just
as hard to get developers who can write easy to understand rules handling
engines in Java (or JavaScript).  Thus, for us there isn't much choice, this
is going to get messy either way.  

<medium sized snip/>

>> I'm not quite sure why you would see procedural logic as being 
>> "better"? Again, we're coming at this from a rules based approach and 
>> as such XSLT seems like a more natural fit...
>
> Agreed. 'better' is the wrong term. Let me use the term 'more natural to 
> programmers nowadays'. I see three ways of implementing this:
>
>  1) procedural engine and declarative adaptation
>  2) declerative engine and procedural adaptation
>  3) two separate engines
>
> the first is the one I'm advocating.
>
Understandable, but what seems at odds with this, is that eventually, Cocoon
is going to run a transform of some form.  Now it may be that XSP allows it
not to really be a functional model, but if one wants to stay pure to the
XML/XSLT model then anyone that uses Cocoon is sooner or later going to have
at least some understanding of functional programming?
 
> for the second, I worry that it will be harder to find people that 
> understand what cocoon is doing and this slows down the community building
>
> for the third, I think nobody will stop people from implementing and 
> proposing alternative flow engines.

Yes, and if blocks gets done properly there should be nothing to stop one
from implementing extensions to the sitemap handler in a modular way. :-)

<small snip/>

>> 1) Presentation flow use case: user has a search screen, search 
>> presents a list of results, user picks from a list of results and sees 
>> the details of a given item.  In the case that the search produces 
>> only a single result you want to jump directly to the details screen 
>> and skip the pick list. (Just for argument lets say that the two 
>> presentation required is complex enough that you really don't want to do
all presentation from a single XSLT.)
>> 
>> With an XSLT template style matcher this is a simple count() of the 
>> data results picking the resultant presentation transform to apply.  I 
>> suspect this is pretty trivial for the flowscript model also?
>
> The above is trivial for the sitemap without even having to use flow. 
> Just write your URI space so that
>
>  /results -> list of results
>
>  /result(*) -> show result {1}
>
> and the count can be done with a stylesheet or with a parameter to a 
> custom generator or with anything you like.
>
> Flow emerges with roundtripping: that is the use of subsequent GET and 
> POST http actions. If you go around 'asking for pages' with GET, there 
> is absolute no need to specifiy any flow whatsoever, a pure sitemap 
> approach is still great.

The multiple/single results are in response to a POST of the search form
input...??? 

<small snip/>

>> However, it gets really interesting when the flow has to cross 
>> business organization boundaries.  Process modeling languages such as 
>> BPEL4WS start to come into play and one ends up wanting to have a 
>> general XML model for describing the problem whether internal or 
>> extranet related.  This doesn't force you into a XSLT processing mode 
>> (for the process modeling language) as a result, but it seems natural 
>> to me?
>
> Have you ever tried? Did you ever estimated the maintenance costs of 
> such an approach (compared to a scripting procedural description) based 
> on your working environment?

Well, that's what we are in the current mode of doing architecture and
design for.  When the current release of our code gets finished up early
next year we'll be jumping into development of generic workflow management
across organizational boundaries (extranet based UI, no WS).  So far the
XML/XSLT model looks pretty clean.  We've got over 600 open protocols each
with different work flows.  The only way to configure all of them is to have
the end users do it.  I can't imagine them writing scripts, I can imagine
them modifying XML templates...

> I'm pretty sure that tool vendors will have XML-exporting of their 
> workflow descriptions, but that doesn't necessarely mean that those XML 
> description will be easy read or cheap to maintain/evolve.

Definitely true. For example, BPEL4WS is a big standard, much more complex
than we really need.  We'll chew off only small subsets if we even end up
using it all...

> moreover, I think it makes sense to 'adapt' those xml descriptions into 
> something that can be directly executed from Cocoon and this is why I 
> think it would be nice to have a way to come up with cocoon-generated 
> flowscripts even if, at first, it seems like FS even to me.

Well, that might work for us.  I'd hate to be the person that attempted to
write the transform!  

I think the bottom line for us will be whether it is easy to modify Cocoon
to add the capabilities we need.  If we end up doing what I've described I
do hope we can donate it back to the community.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org