cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Kiesling <>
Subject Re: Cocoon2 and dynamically generated stylesheets
Date Wed, 31 Oct 2001 12:26:13 GMT
Am Montag, 29. Oktober 2001 18:35 schrieben Sie:
> Hi all,
> I am trying to find a way of setting up a cocoon2 pipeline that uses a
> stylesheet in one XSLT transformation that has been generated by the
> preceeding XSLT transformation.
> This problem is similar to the one described by Tobias Kiesling on Sep. 9th
> 2001.
> As Tobias pointed out, the general process can be achieved by creating an
> XML document in the first step that contains the stylesheet needed in the
> second step as an embedded section. This works using xalan stand-alone.
> Taking into account that xalan looks for a processing instruction in the
> XML document when not supplied with a stylesheet, one might think that
> putting <map:transform src=""/> or even <map:transform/> into the sitemap
> would do the job. From looking at
> org.apache.cocoon.transformation.TraxTransformer I see that omitting the
> src attribute is prohibited and supplying an empty string as its parameter
> causes an exception. I don't yet understand the inner workings of cocoon2
> but wouldn't it be possible to define one of the above options as a way of
> telling the XSLT transformer to look for a PI?

I'm not an expert, but I think the problem here lies with the general way of 
how a transformation is done with TrAX. The stylesheet is compiled into a 
javax.xml.Templates object long before the SaX events of an input document 
occur. It should be possible to use a SAX2DOM converter and then just use an 
XSLT processor like in Cocoon1. But, of course this does not fit the Cocoon2 

> Maybe I am getting something wrong about the way of using cocoon2. Maybe
> any of you guys can tell me about the 'right way' of using cocoon2 in the
> following scenario: I want to post an XML document to the server, which
> describes a structured query and points to another XML document sitting on
> that server on which the query is to be performed. The response should be
> the result of the query, possibly piped through further XSLT
> transformations. My approach was to transform the XML document representing
> the query into another XML document with an embedded stylesheet
> implementing the query by use of XPATH and accessing the 'data' XML
> document via the document() function (using an XPATH expression passed in
> as a variable is not possible :-().

The reason for this is that there is no possibility in XPath to convert a 
string to a nodeset. There are conversion functions from nodeset to string, 
number, boolean, but not the other way around. This seems to be a lack in 
XPath, as it should be fairly easy to add a function like nodeset() that 
takes a string as input, evaluates that string and returns the resulting 

> If you look at it, this process is
> quite elegant. I am not convinced that allowing for such a process would
> break the content-style separation, as not all XSLT-transformations are
> (strictly) about
> representation.

Another thought I had for obtaining the same result as with the embedded 
stylesheet approach was to split the pipeline by extracting the stylesheet 
from the document in one processing step, and to have the XSLT processor 
accept two pipes as input, one for the data to transform and the other one 
for the stylesheet. However this cannot be done easily, as the XSLT processor 
has to buffer the SaX events at least until the whole stylesheet has been 
received. I'm not a cocoon expert, so my thoughts may be wrong.

However, I think that the dynamic creation of stylesheets is a very powerful 
tool that would be good to be supported somehow.


Please check that your question has not already been answered in the
FAQ before posting. <>

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

View raw message