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:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 3:30 PM > To: '[EMAIL PROTECTED]' > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
