From cocoon-dev-return-31564-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Fri Oct 04 15:47:13 2002 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 81765 invoked by uid 500); 4 Oct 2002 15:47:11 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 81711 invoked from network); 4 Oct 2002 15:47:11 -0000 From: "Robert Koberg" To: Subject: RE: XML input module (was: RE: Nice changes!) Date: Fri, 4 Oct 2002 08:45:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021004075709.GB17699@bremen.dvs1.informatik.tu-darmstadt.de> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi, > -----Original Message----- > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de] > Sent: Friday, October 04, 2002 12:57 AM > To: cocoon-dev@xml.apache.org > Subject: Re: XML input module (was: RE: Nice changes!) > > > On 02.Oct.2002 -- 09:47 AM, Hunsberger, Peter wrote: > > This is likely an issue you're going to run into also; mapping XPath to > > random session objects might be possible, but I suspect the two domains > > aren't perfectly isomorphic :-( > > Yes, but since we don't need to work on strings, less so. All these > modules work on Objects and only on some occasions you really want > strings. In the sitemap for example. > > [a highly interesting discussion snipped] > > > No more matchers, no more selectors; just XSLT templates ;-)... Seriously, > > once (if?) XSLT 2 gains regex capabilities I can't really see why a pure > > XSLT pipeline couldn't do everything that matchers and selectors do, therby > > eliminating huge chunks of the current Cocoon code base? > > Maybe, maybe not. One would need to use a lot extension functions to > achieve similar things (e.g. j2ee, databases and stuff) but that might > be portable to other pipeline systems (?). OTOH Apache Cocoon a lot > about SoC and it will need to be seen if that works as well with your > suggested approach. Instead of extensions you could use custom URIResolvers to return the result from anywhere (or just do something and return succes/fail) to an representation usable by a transformation. The separation occurs in the resolver which can be configured to handle your particular needs. best, -Rob > > I believe, many would be interested in your approach. I hope you find > the time to work on it. > > Chris. > -- > C h r i s t i a n H a u l > haul@informatik.tu-darmstadt.de > fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org > For additional commands, email: cocoon-dev-help@xml.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org