cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: [status & RT] design challenges
Date Mon, 08 Apr 2002 08:28:03 GMT
"Andrew C. Oliver" wrote:
> 
> That was stefano's recommendation -- I quoted it.  The idea is to reduce
> multipaths not eliminate them.  *shrug*  -- I took this to mean that two
> commands/elements/syntactical devices that do the same thing but are
> syntactically different are generally to be avoided where possible.  I
> take this as a given.

Yeah, multipaths is when there is more than one way to do it. Perl is a
good example, where multipaths are considered a feature, not a bug -
this is largely a philosophical question. My point was that declarative
semantics tend to increase the number of multipaths, while procedural
semantics reduce them. Procedural algorithms define HOW TO SOLVE a
problem, so one solution is usually enough, so there will be only one
path. Declarative algorithms define WHAT IS the problem and leave the
solution to a black box, which basically tries out every path that it
can find.

> > But if you really want a "next-generation", declarative thing, then you
> > have to stop trying to control everything. Declarative concepts mean that
> > as an application developer you cannot just say "do this now" at any
> > arbitrary point. If you want full control and pre-determined paths, you
> > are probably better of with a procedural approach.
> >
> 
> Web apps are essentially event driven.  SAX is essentially event
> driven.  Given state and user input as data why is this so different
> that it necessitates a procedural approach?

Good point. Web apps are driven by users and a declarative approach
could for example mean the users generate SAX events (the problem) and
you write an XSLT stylesheet (the rules) and the XSLT processor (the
black box) processes problem and rules to generate a solution path.
However, this is a finite state machine and as such there is no context
outside of the current node. Since XSLT does not support backtracking,
there is no way to go back once you're committed to a path. Example:

Consider a multi-page form, where the user inputs data several times and
at last clicks a "process order" button. Suppose that on the last page
the user does something that necessitates going back to a page somewhere
in the middle of the chain, you're out of luck unless you save state
continually, which is cumbersome and error-prone. The usual declarative
technique for this is backtracking, i.e. if at some point in the
processing chain there is a failure, the processor automatically goes
back to the last choice point. So here is what could be done:

1) Implement a truly declarative solution with a finite state machine
and backtracking. You don't need to save state or context in this case.
2) Implement a mixture of declarative and procedural algorithms, using
the best/worst of both worlds. For example an XSLT stylesheet for the
rules (declarative) and a central processor to save state (procedural).
3) Implement a truly procedural solution.

I believe the first option is hard to implement and the second one
kludgy.

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


Mime
View raw message