cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: data goes in, data goes out
Date Fri, 30 Nov 2001 14:15:33 GMT
At 4:07 pm +0100 29/11/01, Stefano Mazzocchi wrote:
>Jeremy Quinn wrote (double quotes mean my words):


>> Incedentally, I spent some time yesterday trying to work out if standard
>> XUpdate transformation could be handled by an XSLT Stylesheet rather than
>> written in Java. I suspect it would be extremely difficult, if not
>> impossible. XSLT is not good at selecting, using dynamic XPaths (am I
>> right?).
>hmmm, from a theorical perspective, if XUpdate cannot be easily
>transformed into a stylesheet, then it means they are sufficiently
>different to make XUpdate existance more interesting. Wouldn't you

This is something I would like to start thinking about, ie. how to
implement XUpdate in such a way it is controlled from the sitemap.
(Basically because this is something I am possibly capable of contributing

There seem to be several options:

	1. XUpdateTransformer
	2. XSLT Stylesheet which knows how to do all XUpdate transformations
	3. XSLT StyleSheet that transforms an XUpdate modification specification
		 into into a new XSLT StyleSheet that is then used to process the data
	4. XSP TagLib
	5. XUpdateAction

Have I missed any?

What information needs to be available?

	1. The new data (Request)
	2. The XUpdate modification specification (from a pseudo protocol url)
	3. The xml fragment to be modified (from a pseudo protocol url)

How might each option work?

	(I am assuming for the moment that we will have some kind of SiteMap
component, that I am calling the "(?) Transformer", that does the job of
serialising a node representing the modified xml fragment to the datasource)

	1. XUpdateTransformer

Use aggregation or XInclude to combine into one "document", the new data,
xupdate spec and xml fragment to be modified.

			<!-- the output of the Request or Stream Generator -->
			<!-- the XUpdate modification specification -->
			<!-- the xml fragment to be modified -->

Pipe this to the XUpdateTransformer, telling it the name of the nodes holding
"request", "update" and "source" (unless we developed a new namespace for
this). Because the XUpdate transformer would need to resolve XPaths (for
copying data) in both the "request" and "source" Nodes.

Pipe this (now with the modified "source") to the (?) Transformer with the
name of the "source" node and a URL to have it serialised to Store.

	2. XSLT Stylesheet which knows how to do all XUpdate transformations

Same as 1. above I believe

	3. XSLT StyleSheet that transforms an XUpdate modification into XSLT
		 that is then used to process the data

Aggregate the "request" and the "source" as above.
Transform this with an XSLT generated by calling a separate pipeline via
the "cocoon:/" protocol that uses a standard XSLT to transform the XUpdate
modification specification into an XSLT for that job (job, not request, so
it can be cached, job represents the source-dtd/operation axis)
Transform this with the magic (?) Transformer as before.
Note: Is this XSLT generation feasible?

	4. XSP TagLib

The site author writes one XSP page for each source-dtd/operation axis in
their project, embedding the same set of XUpdate modification
specifications as above but which are now treated as a TagLib.

The "source" is fed to the TagLib using the XInclude TagLib via a
pseudo-protocol url, the request data is retrieved with inline XSP Request
TagLib tags (inside the XUpdate code).

The output of the TagLib is the modified "source" which is passed down the
pipe to the (?) Transformer (etc).

	5. XUpdateAction

Use whatever Generator you need to produce the response to the user's edit
The XUpdate Action is passed a reference to the "source" and "update" from
the SiteMap. It reads them both in, performs the modification (accessing
parameters in the Environment) and writes out the modified "source"

What other approaches might there be?

Comments anyone?

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
   <phone:+44.[0].20.7737.6831>             <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message