Re: Flow wishlist :)

[Stefano Mazzocchi]

sorry, it took me a while to get back on this

Hunsberger, Peter wrote:

Hmmm, sure. but that is only a very small part of what flow-management is about. How would you keep the state across requests in XSLT?

Same way you would in any other web app....  That's partially why I've got
aggregation of the session, request and other context data feeding this
thing.

in that case you need actions in your pipeline and that means that you are not controlling the flow in your XSLT.

If this is the case, this is nothing different from we have right now in place in terms of flow control.

Ah, we are coming back to the XPathSelector!!!

<map:select type="xpath">
<map:when test="count(data/*) = 0">
<map:transform src="error.xsl"/>
</map:when>
...
</map:select>

This was proposed a while ago but was voted down since the sitemap
routing components shouldn't have a way to access the content of the pipeline.

But sitemap components already have ways to access the content of the pipeline, it's just that currently you have to expose those contents as parameters...

Selectors, matchers and actions have no way to get the content of a pipeline (by design!)

Well if they don't your solution of having a generator create a parameter
for choosing between the count=1 vs. count>1 transforms wouldn't work...

yep, I know that. I was just showing how your proposal of using XSLT as a flow control layer is close to have XPathSelectors and since we already extensively talked about that I could point you to that discussion

The use of XSLT is *clearly* overkill. What you are describing is *NOT*
XSLT: even if it uses the same syntax, the semantics are totally different (in fact, you are mixing XSLT semantics with the sitemap semantics... this cannot possibly be easier to learn/use/maintain than just the sitemap semantics)

That doesn't make sense: in that case you'd have to consider the production of HTML from XML via XSLT a mixing of HTML semantics with XSLT

semantics?

No, because that content is *passive*.

Here, you are mixing xslt and sitemap which are both 'active' content, content that has server-side semantics and will not be passed passivly on.

So, in fact, the complexity of sitemap+flowscript is repeated in XSLT+sitemap, just that your solution doesn't have a way to separate the
two.

I don't think I understand your distinction. Consider for example that
instead of using XSLT I was proposing to use Haskell to write my flow
control manager. Would you have the same objection?

yes, totally, because you would mess with the pipeline creation logic from the flow layer and that enforces concern overlap.

In the flowscript, there is *NO*WAY* you can control how the pipelines are composed since you just call resources using their URIs. It's not the flow manager's concern to describe *how* the resources are generated.

This enforces separation. Might be painful at first, but *very* useful down the road when you can manage and maintain your flow without having to touch (or being afraid others touch!) the resource-producing pipelines and the URI space (which acts as a contract between the flow and the sitemap, enforcing good use of internal contracts and parallel development between separate teams)

Now, your are proposing to have a flow layer that has the ability to control *which* transformer gets executed. I don't care about what syntax you are suggesting to describe that, but I *DO* care about the fact that you are mixing concerns that I want to keep separate.

Do you see my point?

There's no difference between using XSLT+sitemap and using
flowscript+sitemap they both separate things identically.

Exactly, but the code you showed me clearly doesn't.

The difference is
that with flowscript I use callPage (or whatever) to get things back to the
sitemap, with XSLT I use Cocoon:select (or whatever) to get things back to
the sitemap.

Nop, dude. The code you showed me had *explicit* calls to map:transform, which is not the same thing as returning control to the sitemap thru the use of a URI as a contract.

Big difference.

I think you see what I am proposing as part of sitemap, but I think, rather,
that it is part of flow...???

The fact that I can't see where your XSLT belongs, shows you exactly why I think you are mixing concerns.

NOTE: I've been proposing that the flowscript might be generated out of a cocoon pipeline. That implies that you might use whatever declerative markup you want to describe your rules (as people do in a workflow environment) and have a stylesheet transform it into flowscript.

That would:

1) give you a way to keep the rules separated from the resources
2) still use a declarative view of your rule engine (your rules can even be extracted out of a database and cached since I don't think they change that often)
3) no need for custom sitemap transformation components

this is how I would do it. Using XSLT as a pipeline componentization skeleton sounds golden-hammer all the way.

Well that would meet our needs, but if a flowscript can be generated out of
a pipeline what's the difference between using the output of that generator
to control the flow and using the input directly to control the flow of the
pipeline?

Oh, big difference: you keep things separate.

It seems that we're simply skipping a step and making things more
efficient (caching of course pretty well negates that argument)?

No, nothing about efficiency at this point (even if I don't see any reason while what I'm proposing can't be efficient), but architectural.

I repeat: I want things to be kept separate. The flowscript describe the flow between resources and the sitemap describes how these resources are produced.

The contract between them is:

- the URI space of the cocoon-handled resources
- the parameters the various resources consume
- the parameters the various resources produce

No matter *what* syntax you propose to describe the flow layer, I will be against it if it doesn't allow this separation as a I described it because it would be *nothing* different from what we have today with actions.

Consider the flow manager a black box for a moment.  If I plug in version X
or version Y of that black box it shouldn't change the way the rest of the
pipeline views the metadata.

Totally agreed, but this is only *IF* that flow manager is a block and that is true *only* if the concepts they implement are the same.

Your bunch of data is always represented as nodes (since it's XML and must be processed that way). Your bunch of metadata is always represented as objects (since it's not XML and should not be processed that way).

But all my metadata is XML and I have good reasons for processing it that
way...

Oh, gosh, golden-hammer all over the place.

XML is a syntax, not a data model. Your data model in the pipeline is SAX events. Do you need to process your metadata as a stream of events? I'm positive you don't.

Arg, too hasty of explanation... As I've pointed out, much of this is driven
across organizational boundaries.  As such, we've got a common syntax for
describing our metadata and it happens to be XML.  Do I need to process this
as a stream of events?  I don't think so but it makes me pause to think
about the possibilities: one persons meta-data is another persons data.

True. But the data model remains the same for both you and me.

We've got three separate layers of meta-data in our model already (well we
should have three, currently we have two and a mix of concerns as a result).
As you climb up and down the abstraction tree you deal with different
concerns: business process, work flow, finally, presentation flow.  It's
nice to try and containerize presentation flow, but work flow always implies
presentation flow (though not vice-versa).  Similarly, business process
implies a bunch of things about work flow. I haven't come to grips with what
that implies for this whole model but it suggests that there are several
more layers of abstraction and separation of concerns to be modeled before
this whole thing is done...

Agreed. I've already said that 'flowscript' is going to mix concerns between 'presentation flow' and 'work flow'. And this is the reason why I'm seriously thinking about allowing flows to be created with cocoon pipelines and imported together because that way I could have part of my flow as a flowscript and part of it as a WFDL (workflow description language, a standard declarative markup for workflow definitons) that can be 'transformed' into javascript by a cocoon pipeline.

In that case, I can further separate things.

But my point is that sitemap/flowscript separation is complete. I was challenging your concept of using XSLT to see if the S+F model didn't work, but I think it still does because I think it's your model that is weaker (SoC-wise, of course) [no offense, please, just trying to be objective on what I see so far]

You are telling me that your metadata is contained in a tree-structured data model and you like it keep it so and you would like to use xpath to query it.

Great, write your create sitemap selector that connects to your rule database, gets an Xml representation, create a DOM, and query that DOM with an XPath query layer. It's no more than 10 lines of java code if you know what avalon components to use.

I tend to think that I don't need a pipeline for things that are not stream-based. But that's me.

Interesting possibility.  The thing that is maybe missing is that I want to
forward the partially processed sax streams.  I don't really need this other
than for efficiency of processing.

Oh, look, I wouldn't use 'efficiency' here at all. You are basically saying that you have your data in XML, you want to aggregate it (that means sending *all* your data thru the pipeline and calling SAX events all over the place) for a few transformations stages to react on *some* of that information.

I would call for 'inefficiency' right there. You are basically sending thru *all* your metadata even if you don't know you're going to use it or not.

I would think that this is against IoC: if should be the transformation stage to call your metadata only when it requires some of it. It shouldn't be you pushing all your metadata down the transformer's throwt. That's utterly inefficient.

I've been pretty comfortable that we will not require sitemap changes or at
least no changes to the sitemap language.  I do think we might want to use
the same hooks as the flow manager.

Nop, because the flow manager will *not* have hooks on how the sitemap pipelines will be composed.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]