cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McDonald, Bruce" <Bruce.McDon...@bankofamerica.com>
Subject RE: Crusading for the XSLT document() function
Date Mon, 20 Oct 2003 13:08:44 GMT


-----Original Message-----
From: Robert Koberg [mailto:rob@koberg.com]
Sent: Friday, October 17, 2003 6:31 PM
To: users@cocoon.apache.org
Subject: RE: Crusading for the XSLT document() function


It is amazing that no one has commented on this post. Perhaps it is because
the beta-omega developers do not want to show anything that contradicts the
alpha developer (fear of agora Siberia perhaps...).

You show a way to use cocoon and the document function in a harmonious (and
a very useful) way.

Are people simply closing their eyes to new ways (although standard and
accepted by some extremely intelligent people in XML/XSL) or have they
invested too deeply in _the cocoon way_ or do they simply refuse to think
about (and therefore feel no need to comment)?

----

One more benefit of using the document function as opposed to /proprietary/
cocoon ways is that you can perform simple transforms outside of cocoon or
even pick up your XSL and leave for another solution. -- NO LOCK IN --

-Rob

> -----Original Message-----
> From: Horsfield, Peter A. [mailto:peter.horsfield@ngc.com]
> Sent: Thursday, October 16, 2003 3:30 PM
> To: 'users@cocoon.apache.org'
> 
> 
> 	document('cocoon:/myinternalpipeline');
> 
> 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.
> 
> Regards,
> 
> Peter
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message