cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 22:24:18 GMT
Leo Sutic <> responds:
> > From: Hunsberger, Peter []
> > > Hunsberger, Peter wrote:
> > > > As I discussed with you when the flow sitemap integration
> > > discussions
> > > > where in full swing I do have a long term agenda (XSLT
> > > managed flow)
> > > > and I would like to see a way of including it in Cocoon without 
> > > > breaking existing functionality...
> > > 
> > > This is the wrong approach.
> > > 
> > > Peter, you don't want XSLT managed flow. What you want is 
> a solution 
> > > to the problem that you have decided that XSLT managed flow is a
> > > solution for. (Did you follow me there?)
> > > 
> > 
> > I don't know why you presume to know what we want?  It's not
> > XSLT based flow specifically
> OK, my mistake. I assumed you wanted a solution to your 
> problem, and since you said you wanted XSLT based flow (your 
> long term agenda) I assume that was what you wanted.

Fair enough.  I do have a long term agenda, whether that ever happens is
almost irrelevant to the issue at hand....  At the moment, I'm just
trying to present evidence that Sylvain's and Marc's proposal is

> My point was that the proposals in general shouldn't be "I 
> want *this* 
> solution" but rather "I want a solution that can solve *this*".
Sure, I argue that point all the time with my Business Analysts.  In
this case, we've been through over 2 years of problem analysis,
architecture and detailed design.  Some of it's been presented on the
various Cocoon lists over the years, most of it hasn't.  

A little background: we're trying to implement a generic system for
managing Clinical trials.  We happen to have 1600 open trials each of
which collects 1000's of data elements, each in a slightly different
manner that gets revised on an ongoing basis.  All the data has to be
shared with 1000's of rules on who can see what when. I'll just ask you
to take my word for it that the problem we're trying to solve isn't easy
(several people have claimed it impossible) and requires some pretty
unusual hoop jumping... 

> I was trying to present your request in a different form - 
> that the important thing wasn't the adoption of a specific 
> solution, but the solution of a specific problem.
Once you're familiar with them it's pretty hard to see rule based
systems as anything but a very generalized type of solution.  It's just
that they burn a lot of resources so traditionally they've been viewed
as a solution of last resort.  In our case we've acknowledged their
costs but view them as acceptable for our problem domain.  Having bought
into that decision I tend to be a little myopic when people suggest that
there might be other ways to view the problem.  Sorry about that...

View raw message