commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Morphos] Food for thoughts
Date Fri, 09 Aug 2002 20:02:58 GMT

Sven Kuenzler wrote:
> Nicola Ken Barozzi wrote:
>> [ More on the rest to follow this weekend ]
>>>>> - Merging two Morphers? E.g. 
>>>>> XMLOutputtingMorpher+XSLStylesheetOutputtingMorpher both connect to 
>>>>> a XSLTMorpher doing the transformation
>>>> Could you please elaborate more?
>>> Yes. But I think we postpone this ATM.
>> Ah, shucks ;-/ It seemed so interesting ;-D
> Well, the idea behind this was quite simple: For example, transforming 
> XML via XSLT effectively needs two XML "flavor style" inputs. So instead 
> of viewing the XSLT stylesheet (URL or file or whatever) as parameter, 
> what would happen if you treat it as kind of "second input" to the Morpher?

Ah, now I understand.

> Such a solution could benefit from all the Stream2Foobar morphers to 
> access your stylesheet. If you have a stylesheet parameter, you are 
> limited to whatever is hardwired as acceptable stylesheet source in your 
> Morpher.

Honestly, I started out having the _fear_ that this thing would come up.
It always comes up in pipeline systems, and came up also in Cocoon.

But let's try to formalize all of this a bit with a random thought RT.

A Morpher has an input and an output.
A Pipeline chains these Morphers.
This is all there is to Morphos.

Another system can think of routing objects from one Morpher to another 
or to multiple Morphers, aggergating, splitting, selecting, and doing 
all sorts of combinations.
But this is another project, that I would like to do, but after I get 
Morphos right.

What you talk about is a /similar/ thing but not quite.
In fact I talk about components that operate on content, while XSLT is 
not the primary content, but a descriptor for a transformation, a 
"parameter" conceptually.

If we make this parameter set not by filename, but by a Stream, we can 
manually hook a Morpher to it, as you say, but still this doesn't change 
the structure of the Morphers.

Maybe the problem lies more in how we give parameters; if they are 
consistent, patterns can be reused.

For example, Cocoon makes a resolver available to Generation Components; 
personally I think that we must strive to separate as much as possible 
the location and the generation phases, but we are already doing it... 
so I guess that it's already ok.


So, it seems we need to remember that we shall never use Resource 
Locators to our content Morphers, only to the ones that Morph a Location 
to an actual object.

This means that the InputSource2SAX Morpher is wrong. We should have an 
InputSource2StreamMorpher and a Stream2SAXMorpher, so that it's more 

The point is that we cannot formalize this, because an Object is an 
Object , we cannot know if it's a resource identifier of some sort, 
because a computer cannot understand the semantics.

But if we keep to the simple rule of separating Locators to actual 
Morphers, we are going to have more flexibility.

Hey, what about making a Locator interface?
It could be something like:

    public void setLocation(Object location);
    public boolean isLocationReachable();
    public Object locate();
    public ObjectFlavor getFlavor();

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message