cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Horsfield, Peter A." <>
Subject Crusading for the XSLT document() function
Date Thu, 16 Oct 2003 22:30:17 GMT


SoC... Caching... Virtual URI space... Pipeline reuse...

All it would take is for Cocoon to keep an eye out for calls to the 
SourceResolver, and perhaps for request parameters to be 
passed smartly. Better yet, force all document('...') requests be 
Cocoon internal protocol requests.

Counter points:

Source Pure XML - 
	You get one pure XML source indirectly
	AND you get to use all the existing XML 
	application specific tools for your other source.

Aggregation - 
	Aggregation is not the force for SoC it is presented as.
	It is good only for simple single level cases. As soon
	as you aggregate aggregations, you've lost the case.

Speed - 
	In an attempt to speed up processing, I removed the 
	document function, and cincluded the data 
	into the source. It made no difference. (Solaris 8 - 
	there were other speed issues at the time).

DOM / SAX - 
	Aggregation pumps entire blocks of SAX events. This is
	fine, XSLT may be worse. But XSLT (or STX) implementations 
	do have the freedom to optimize this stuff. The semantics of 
	aggregation do not allow this freedom.

Now if the developers of Cocoon think that using the document function is 
not a good use of Cocoon, then so be it. I think that in conjunction with
the Cocoon protocol, it is a powerful feature that supports SoC.

When it comes down to it aggregation and the document function do fulfil
the same need. The only reason I would pick the XSLT document function 
over aggregation, is... it just feels right.

After writing this all down, I think I've decided that both aggregation and
document() suck in Cocoon. There has got to be a better way. 

Cocoon 3, perhaps.




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

View raw message