Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 73965 invoked from network); 16 Oct 2003 22:33:39 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 16 Oct 2003 22:33:39 -0000 Received: (qmail 88735 invoked by uid 500); 16 Oct 2003 22:33:17 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 88481 invoked by uid 500); 16 Oct 2003 22:33:15 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: users@cocoon.apache.org Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 88460 invoked from network); 16 Oct 2003 22:33:15 -0000 Received: from unknown (HELO xcgmd811.ngxcgmdr1.northgrum.com) (155.104.240.101) by daedalus.apache.org with SMTP; 16 Oct 2003 22:33:15 -0000 Received: by xcgmd811.ngxcgmdr1.northgrum.com with Internet Mail Service (5.5.2656.59) id <40RT2S9D>; Thu, 16 Oct 2003 15:32:37 -0700 Message-ID: From: "Horsfield, Peter A." To: "'users@cocoon.apache.org'" Subject: Crusading for the XSLT document() function Date: Thu, 16 Oct 2003 15:30:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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