From zvia@netmanage.co.il Tue Nov 9 19:28:58 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22214 invoked from network); 9 Nov 1999 19:28:58 -0000 Received: from nmi-gate.netmanage.co.il (root@156.27.240.10) by apache.org with SMTP; 9 Nov 1999 19:28:58 -0000 Received: from netmanage.co.il (eng-ts-p1.netmanage.co.il [156.27.241.181]) by nmi-gate.netmanage.co.il (8.9.2/8.9.1) with ESMTP id VAA17395; Tue, 9 Nov 1999 21:29:09 +0200 (IST) Message-ID: <382876CB.57D64D56@netmanage.co.il> Date: Tue, 09 Nov 1999 21:32:27 +0200 From: Zvi Avraham Reply-To: zvia@netmanage.co.il X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Unable to checkout sources from new CVS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is what I get: cvs checkout -P xml-cocoon (in directory C:\) cvs checkout: warning: unrecognized response `cvs: setgroups: Operation not permitted' from cvs server cvs server: cannot find module `xml-cocoon' - ignored cvs [checkout aborted]: cannot expand modules *****CVS exited normally with code 1***** From brian@collab.net Wed Nov 10 07:48:47 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 9798 invoked from network); 10 Nov 1999 07:48:47 -0000 Received: from lumberjack.collab.net (HELO yaz.hyperreal.org) (209.246.26.186) by apache.org with SMTP; 10 Nov 1999 07:48:47 -0000 Received: (qmail 1477 invoked by uid 1000); 10 Nov 1999 07:48:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Nov 1999 07:48:45 -0000 Date: Tue, 9 Nov 1999 23:48:45 -0800 (PST) From: Brian Behlendorf X-Sender: brian@yaz.hyperreal.org To: Zvi Avraham cc: cocoon-dev@xml.apache.org Subject: Re: Unable to checkout sources from new CVS In-Reply-To: <382876CB.57D64D56@netmanage.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That's now fixed, give it another try. Brian On Tue, 9 Nov 1999, Zvi Avraham wrote: > This is what I get: > > cvs checkout -P xml-cocoon (in directory C:\) > cvs checkout: warning: unrecognized response `cvs: setgroups: Operation > not permitted' from cvs server > cvs server: cannot find module `xml-cocoon' - ignored > cvs [checkout aborted]: cannot expand modules > > *****CVS exited normally with code 1***** From zvia@netmanage.co.il Sat Nov 13 13:04:56 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 5463 invoked from network); 13 Nov 1999 13:04:56 -0000 Received: from alpha.netvision.net.il (194.90.1.13) by apache.org with SMTP; 13 Nov 1999 13:04:56 -0000 Received: from netmanage.co.il (eng-ts-p2.netmanage.co.il [156.27.241.182]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id PAA23064; Sat, 13 Nov 1999 15:04:42 +0200 (IST) Message-ID: <382D62CA.1301F4C8@netmanage.co.il> Date: Sat, 13 Nov 1999 15:08:27 +0200 From: Zvi Avraham Reply-To: zvia@netmanage.co.il X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: DataChannel XPages ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefano, you once mentioned DataChannel's XPages, I also read about them in : http://industry.java.sun.com/javanews/stories/story2/0,1072,20294,00.html "- XPages, from DataChannel -- an XML application markup language for quickly building data-driven, cross-platform Web applications that integrate disparate data sources. An XPage application is defined by an XML file that aggregates multiple data sources, makes that data URL addressable and defines custom methods to access that data. The DataChannel submission includes Java code for a servlet based engine" Is this will be integrated with XSP ? I don't find it on xml.apache.org, what's the status of it ? Regards Zvi From stefano@apache.org Sun Nov 14 13:20:13 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 18380 invoked from network); 14 Nov 1999 13:20:13 -0000 Received: from pop.systemy.it (194.20.140.28) by apache.org with SMTP; 14 Nov 1999 13:20:13 -0000 Received: from apache.org (pv17-pri.systemy.it [194.21.255.17]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id OAA08136 for ; Sun, 14 Nov 1999 14:20:08 +0100 Message-ID: <382D838E.66600F9F@apache.org> Date: Sat, 13 Nov 1999 16:28:14 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: DataChannel XPages ... References: <382D62CA.1301F4C8@netmanage.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Zvi Avraham wrote: > > Stefano, > > you once mentioned DataChannel's XPages, > I also read about them in : > http://industry.java.sun.com/javanews/stories/story2/0,1072,20294,00.html > > "- XPages, from DataChannel -- an XML application markup language for > quickly building data-driven, cross-platform Web applications that > integrate disparate data sources. An XPage application is defined by an > XML file that aggregates multiple data sources, makes that data URL > addressable and defines custom methods to access that data. The > DataChannel submission includes Java code for a servlet based engine" > > Is this will be integrated with XSP ? At this point, no. We'll have both XPages _and_ XSP and we'll see what the users decide/like. > I don't find it on xml.apache.org, > what's the status of it ? DataChannel is working on cleaning the source code up to donate it to the project. It will happen soon. I haven't seen the source code yet, just a few example and they sound like a mix between DCP, XSP and a PDOM, still allowing page compilation but also offering some content/logic separation. The PDOM capabilities might be attractive, but I need to see how this works in practive before make any judgement since I'm kind of skeptical on using DOM as a DBMS API. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From balld@phoenix.webslingerZ.com Sun Nov 14 22:16:48 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 8063 invoked from network); 14 Nov 1999 22:16:48 -0000 Received: from phoenix.webslingerz.com (balld@206.66.49.24) by apache.org with SMTP; 14 Nov 1999 22:16:48 -0000 Received: from localhost (balld@localhost) by phoenix.webslingerZ.com (8.8.7/8.8.7) with ESMTP id RAA01470 for ; Sun, 14 Nov 1999 17:18:40 -0500 Date: Sun, 14 Nov 1999 17:18:40 -0500 (EST) From: Donald Ball To: cocoon-dev@xml.apache.org Subject: Re: DataChannel XPages ... In-Reply-To: <382D838E.66600F9F@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 13 Nov 1999, Stefano Mazzocchi wrote: > > I don't find it on xml.apache.org, > > what's the status of it ? > > DataChannel is working on cleaning the source code up to donate it to > the project. It will happen soon. > > I haven't seen the source code yet, just a few example and they sound > like a mix between DCP, XSP and a PDOM, still allowing page compilation > but also offering some content/logic separation. > > The PDOM capabilities might be attractive, but I need to see how this > works in practive before make any judgement since I'm kind of skeptical > on using DOM as a DBMS API. I am as well but it sounds interesting. Is there an API or any docs on this? - donald From Simon@BALR.com Mon Nov 15 23:02:31 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23134 invoked from network); 15 Nov 1999 23:02:31 -0000 Received: from wagmail2.walgreens.com (207.70.75.100) by apache.org with SMTP; 15 Nov 1999 23:02:31 -0000 Received: from NotesMTA.walgreens.com (mailhost4.walgreens.com [207.70.76.9]) by wagmail2.walgreens.com (8.9.1b+Sun/8.9.1) with SMTP id RAA24501 for ; Mon, 15 Nov 1999 17:02:39 -0600 (CST) Received: from net3782.Walgreens.com ([60.130.7.174]) by NotesMTA.walgreens.com (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 8625682A.007E9007; Mon, 15 Nov 1999 17:02:24 -0600 Message-ID: <028301bf2fbd$3fddfb20$ae07823c@Walgreens.com> From: "Simon McClenahan" To: "Cocoon Dev" Subject: Re: When, or where is latest development release? Date: Mon, 15 Nov 1999 17:00:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I'm replying to this new list instead of the Working Dogs list, hope = that's OK ... I downloaded and installed GNU's CVS, and I've followed the concept of = AnonCVS outlined at http://xml.apache.org/cvs.html . Having not used CVS = before, I briefly RTFM'd and managed to get some sort of listing, but I = could not find Cocoon. Can someone give me some basic CVS commands to be = able to grab the current Cocoon source as anoncvs? I then discovered the Daily Archives at = http://www.working-dogs.com/daily/ . So I got the latest version and did = a make, but I got a bunch of "Package X not found in import" errors for = all the parsers and xslt processors and the ecmascript interpreter. So = this means that I am required to download all of these packages to be = able to compile Cocoon! Is there a definitive list of required packages? = Can I assume that Cocoon2 will use Xerces/Xalan in the distribution, = and/or SAX, and not the individual packages mentioned? Speaking of Cocoon2, where, and when? It was said that there would be a = working version by the end of the year, what are the chances of someone = getting something working within the next week or two? I'm just asking, = not trying to pressure anyone or seem ungrateful. cheers, Simon ------------------------------------------- From: "Donald Ball" Date: Tue, 9 Nov 1999 02:05:05 -0500 (EST) On Mon, 8 Nov 1999, Simon McClenahan wrote: > The download area has 1.5, but the online documentation says 1.6-dev . > I really want to try the XT processor. Is there a .jar file I can > download, or do I just have to compile it myself from the emails I > receive on this list? If this code is in CVS, could a nightly or > regularly scheduled build be performed, available for download? The code is in CVS. You should be able to simply grab the new = processor's source code, compile it, and it to the jar for 1.5 (or just compile a whole new jar, whichever). I cannot schedule a nightly build from CVS = but vote +1 for this to happen. I guess we should beg jon* for help? - donald From kvisco@exoffice.com Mon Nov 15 23:13:33 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 3109 invoked from network); 15 Nov 1999 23:13:33 -0000 Received: from unknown (HELO titan.exoffice.com) (root@204.156.146.48) by apache.org with SMTP; 15 Nov 1999 23:13:33 -0000 Received: from exoffice.com ([204.156.146.57]) by titan.exoffice.com (8.9.3/8.9.3) with ESMTP id QAA17309 for ; Mon, 15 Nov 1999 16:08:00 -0800 Message-ID: <38309423.C361116C@exoffice.com> Date: Mon, 15 Nov 1999 15:15:47 -0800 From: Keith Visco X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: When, or where is latest development release? References: <028301bf2fbd$3fddfb20$ae07823c@Walgreens.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You are not required to download all the support packages, just remove (or rename the class so that is does not have ".java") the XSL processor and XML parser wrapper classes for packages you do not have. --Keith Simon McClenahan wrote: > I'm replying to this new list instead of the Working Dogs list, hope that's OK ... > > I downloaded and installed GNU's CVS, and I've followed the concept of AnonCVS outlined at http://xml.apache.org/cvs.html . Having not used CVS before, I briefly RTFM'd and managed to get some sort of listing, but I could not find Cocoon. Can someone give me some basic CVS commands to be able to grab the current Cocoon source as anoncvs? > > I then discovered the Daily Archives at http://www.working-dogs.com/daily/ . So I got the latest version and did a make, but I got a bunch of "Package X not found in import" errors for all the parsers and xslt processors and the ecmascript interpreter. So this means that I am required to download all of these packages to be able to compile Cocoon! Is there a definitive list of required packages? Can I assume that Cocoon2 will use Xerces/Xalan in the distribution, and/or SAX, and not the individual packages mentioned? > > Speaking of Cocoon2, where, and when? It was said that there would be a working version by the end of the year, what are the chances of someone getting something working within the next week or two? I'm just asking, not trying to pressure anyone or seem ungrateful. > > cheers, > Simon > > ------------------------------------------- > From: "Donald Ball" > Date: Tue, 9 Nov 1999 02:05:05 -0500 (EST) > > On Mon, 8 Nov 1999, Simon McClenahan wrote: > > > The download area has 1.5, but the online documentation says 1.6-dev . > > I really want to try the XT processor. Is there a .jar file I can > > download, or do I just have to compile it myself from the emails I > > receive on this list? If this code is in CVS, could a nightly or > > regularly scheduled build be performed, available for download? > > The code is in CVS. You should be able to simply grab the new processor's > source code, compile it, and it to the jar for 1.5 (or just compile a > whole new jar, whichever). I cannot schedule a nightly build from CVS but > vote +1 for this to happen. I guess we should beg jon* for help? > > - donald From stefano@apache.org Mon Nov 15 23:35:29 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 24554 invoked from network); 15 Nov 1999 23:35:29 -0000 Received: from pop.systemy.it (194.20.140.28) by apache.org with SMTP; 15 Nov 1999 23:35:29 -0000 Received: from apache.org (pv15-pri.systemy.it [194.21.255.15]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id AAA13719 for ; Tue, 16 Nov 1999 00:35:16 +0100 Message-ID: <38309936.BB1C9BD7@apache.org> Date: Tue, 16 Nov 1999 00:37:26 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: When, or where is latest development release? References: <028301bf2fbd$3fddfb20$ae07823c@Walgreens.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simon McClenahan wrote: > > I'm replying to this new list instead of the Working Dogs list, hope that's OK ... > > I downloaded and installed GNU's CVS, and I've followed the concept of AnonCVS outlined at http://xml.apache.org/cvs.html . Having not used CVS before, I briefly RTFM'd and managed to get some sort of listing, but I could not find Cocoon. Can someone give me some basic CVS commands to be able to grab the current Cocoon source as anoncvs? > > I then discovered the Daily Archives at http://www.working-dogs.com/daily/ . So I got the latest version and did a make, but I got a bunch of "Package X not found in import" errors for all the parsers and xslt processors and the ecmascript interpreter. So this means that I am required to download all of these packages to be able to compile Cocoon! Is there a definitive list of required packages? Can I assume that Cocoon2 will use Xerces/Xalan in the distribution, and/or SAX, and not the individual packages mentioned? > > Speaking of Cocoon2, where, and when? It was said that there would be a working version by the end of the year, what are the chances of someone getting something working within the next week or two? I'm just asking, not trying to pressure anyone or seem ungrateful. Sorry, I'm really busy and the process of moving from java.apache to xml.apache will take a while. Sorry about that, please be patient a little more. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From Simon@BALR.com Tue Nov 16 15:44:08 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 27405 invoked from network); 16 Nov 1999 15:44:08 -0000 Received: from wagmail2.walgreens.com (207.70.75.100) by apache.org with SMTP; 16 Nov 1999 15:44:08 -0000 Received: from NotesMTA.walgreens.com (mailhost4.walgreens.com [207.70.76.9]) by wagmail2.walgreens.com (8.9.1b+Sun/8.9.1) with SMTP id JAA07630; Tue, 16 Nov 1999 09:44:15 -0600 (CST) Received: from net3782.Walgreens.com ([60.130.7.174]) by NotesMTA.walgreens.com (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 8625682B.00566D38; Tue, 16 Nov 1999 09:44:00 -0600 Message-ID: <004b01bf3049$2e146e60$ae07823c@Walgreens.com> From: "Simon McClenahan" To: "Cocoon Dev" Subject: Running processors from command line Date: Tue, 16 Nov 1999 09:42:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I don't suppose there could be a command-line interface to the = SQLProcessor? Something like: java org.apache.cocoon.processor.sql.SQLProcessor or an abstract interface to any processor: java org.apache.cocoon.processor type=3Dsql cheers, Simon From bmclaugh@algx.net Wed Nov 17 16:51:56 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 29871 invoked from network); 17 Nov 1999 16:51:56 -0000 Received: from dfwns08.algx.net (216.99.225.37) by apache.org with SMTP; 17 Nov 1999 16:51:56 -0000 Received: from dfwbmclaugh ([216.99.224.6]) by dfwns08.algx.net (Post.Office MTA v3.5.2 release 221 ID# 0-56809U5000L5300S0V35) with SMTP id net for ; Wed, 17 Nov 1999 10:51:51 -0600 Message-ID: <00fe01bf311c$07465b80$8c0f0a0a@allegiancetelecom.com> From: "Brett McLaughlin" To: Subject: Cocoon and Tomcat Date: Wed, 17 Nov 1999 10:51:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Has anyone had any luck getting Cocoon to work with Tomcat? I think I saw something about this recently, but never really heard how it was done. Thanks. -Brett From balld@phoenix.webslingerZ.com Wed Nov 17 20:05:27 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 3612 invoked from network); 17 Nov 1999 20:05:27 -0000 Received: from phoenix.webslingerz.com (balld@206.66.49.24) by apache.org with SMTP; 17 Nov 1999 20:05:27 -0000 Received: from localhost (balld@localhost) by phoenix.webslingerZ.com (8.8.7/8.8.7) with ESMTP id PAA29495 for ; Wed, 17 Nov 1999 15:06:40 -0500 Date: Wed, 17 Nov 1999 15:06:39 -0500 (EST) From: Donald Ball To: Cocoon Dev Subject: Re: Running processors from command line In-Reply-To: <004b01bf3049$2e146e60$ae07823c@Walgreens.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 Nov 1999, Simon McClenahan wrote: > I don't suppose there could be a command-line interface to the > SQLProcessor? Something like: > > java org.apache.cocoon.processor.sql.SQLProcessor Uh, you can. you just run the main cocoon class (org.apache.cocoon.Cocoon) on an XML file that contains the PI... - donald From nader@makeit.no Thu Nov 18 09:48:07 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 25759 invoked from network); 18 Nov 1999 09:48:07 -0000 Received: from unknown (HELO home.netti.nu) (root@195.159.89.21) by apache.org with SMTP; 18 Nov 1999 09:48:07 -0000 Received: from beta (mp-217-211-17.daxnet.no [193.217.211.17]) by home.netti.nu (8.9.1/8.9.1) with SMTP id JAA18648 for ; Thu, 18 Nov 1999 09:53:06 +0100 Message-ID: <000701bf31a8$60414420$0326f081@beta> From: "Nader Aeinehchi" To: Subject: Re: Running processors from command line Date: Thu, 18 Nov 1999 10:36:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Hi Donald: This is the first I ever participate in Free Code Project. I have registered myself in the CoCoon Project, but I can not see the status of the project, where the existing/sample code or architecture is. Can you guide me? Best Regards.... -----Original Message----- From: Donald Ball To: Cocoon Dev Date: Wednesday, November 17, 1999 10:02 PM Subject: Re: Running processors from command line >On Tue, 16 Nov 1999, Simon McClenahan wrote: > >> I don't suppose there could be a command-line interface to the >> SQLProcessor? Something like: >> >> java org.apache.cocoon.processor.sql.SQLProcessor > >Uh, you can. you just run the main cocoon class (org.apache.cocoon.Cocoon) >on an XML file that contains the PI... > >- donald > From pier@apache.org Thu Nov 18 10:26:28 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 10998 invoked from network); 18 Nov 1999 10:26:28 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by apache.org with SMTP; 18 Nov 1999 10:26:28 -0000 Received: from sun(sun.betaversion.org[192.168.1.2]) (1205 bytes) by kali.betaversion.org via smail with P:smtp/R:internet/T:smtp (sender: ) id for ; Thu, 18 Nov 1999 02:28:07 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <01b501bf31af$c5cf7ad0$0201a8c0@betaversion.org> From: "Pierpaolo Fumagalli" To: References: <000701bf31a8$60414420$0326f081@beta> Subject: Re: Running processors from command line Date: Thu, 18 Nov 1999 02:29:19 -0800 Organization: The Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: Nader Aeinehchi > > Hi Donald: > > This is the first I ever participate in Free Code Project. I have > registered myself in the CoCoon Project, but I can not see the status of the > project, where the existing/sample code or architecture is. > > Can you guide me? You can checkout the code from the public cvs archive of xml.apache.org... Get a cvs client (www.cyclic.org or www.wincvs.org). Take a look here for more informations http://xml.apache.org/cvs.html Pier From stefano@hyperreal.org Sat Nov 20 01:13:23 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 215 invoked by uid 2016); 20 Nov 1999 01:13:23 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 29840 invoked by uid 218); 20 Nov 1999 01:12:24 -0000 Date: 20 Nov 1999 01:12:24 -0000 Message-ID: <19991120011224.29839.qmail@hyperreal.org> From: stefano@hyperreal.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon changes.xml todo.xml LICENSE README index.html Todo stefano 99/11/19 17:12:18 Modified: . LICENSE README Added: . changes.xml todo.xml Removed: . index.html Todo Log: Cleaning up and moving to total XML docs Revision Changes Path 1.2 +46 -50 xml-cocoon/LICENSE Index: LICENSE =================================================================== RCS file: /home/cvs/xml-cocoon/LICENSE,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- LICENSE 1999/11/06 13:19:03 1.1 +++ LICENSE 1999/11/20 01:11:57 1.2 @@ -1,53 +1,49 @@ -/* ==================================================================== - * Copyright (c) 1995-1999 The Apache Group. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * - * 3. All advertising materials mentioning features or use of this - * software must display the following acknowledgment: - * "This product includes software developed by the Apache Group - * for use in the Apache HTTP server project (http://www.apache.org/)." - * - * 4. The names "Apache Server" and "Apache Group" must not be used to - * endorse or promote products derived from this software without - * prior written permission. For written permission, please contact +/* + * ============================================================================ + * The Apache Software License, Version 1.1 + * ============================================================================ + * + * Copyright (C) 1999 The Apache Software Foundation. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without modifica- + * tion, are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, + * this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * + * 3. The end-user documentation included with the redistribution, if any, must + * include the following acknowledgment: "This product includes software + * developed by the Apache Software Foundation (http://www.apache.org/)." + * Alternately, this acknowledgment may appear in the software itself, if + * and wherever such third-party acknowledgments normally appear. + * + * 4. The names "Cocoon" and "Apache Software Foundation" must not be used to + * endorse or promote products derived from this software without prior + * written permission. For written permission, please contact * apache@apache.org. + * + * 5. Products derived from this software may not be called "Apache", nor may + * "Apache" appear in their name, without prior written permission of the + * Apache Software Foundation. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, + * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE + * APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- + * DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS + * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * This software consists of voluntary contributions made by many individuals + * on behalf of the Apache Software Foundation and was originally created by + * Stefano Mazzocchi . For more information on the Apache + * Software Foundation, please see . * - * 5. Products derived from this software may not be called "Apache" - * nor may "Apache" appear in their names without prior written - * permission of the Apache Group. - * - * 6. Redistributions of any form whatsoever must retain the following - * acknowledgment: - * "This product includes software developed by the Apache Group - * for use in the Apache HTTP server project (http://www.apache.org/)." - * - * THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY - * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR - * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR - * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; - * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, - * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED - * OF THE POSSIBILITY OF SUCH DAMAGE. - * ==================================================================== - * - * Contributors... origin.. credits.. */ - - - 1.2 +53 -13 xml-cocoon/README Index: README =================================================================== RCS file: /home/cvs/xml-cocoon/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- README 1999/11/06 13:19:03 1.1 +++ README 1999/11/20 01:11:58 1.2 @@ -1,26 +1,66 @@ - Apache - Version 1.3 (and up) - + C O C O O N @@VERSION@@ + + What is it? ----------- + Cocoon is a 100% pure Java publishing framework that relies on + new W3C technologies (such as XML, and XSL) to provide web content. + + The Cocoon project aims to change the way web information is created, + rendered and delivered. This new paradigm is based on fact that document + content, style and logic are often created by different individuals or + working groups. + + Cocoon aims to a complete separation of the three layers, allowing the + three layers to be indipendently designed, created and managed, reducing + management overhead, increasing work reuse and reducing time to market. + + Where is it? + ------------ - The Latest Version - ------------------ + The home page for the Cocoon project can be found in the Apache XML Project + web site (http://xml.apache.org/cocoon/). There you also find information + on how to download the latest release as well as all the other information + you might need regarding this project. - Documentation - ------------- - Installation + Requirements ------------ + + Cocoon is implemented both as a Java servlet and a Java command line + application. The following requirements exist for installing it: + + o A Java 1.1 or later compatible virtual machine for your operating system. + + o Server API 2.x Servlet Engine (optional for command line operation). + + o XML Parser with DOM support. + + o XSL Processor with DOM support. + + + Installation Instructions and Documentation + ------------------------------------------- + + The documentation available as of the date of this release is + included in the "docs/" directory. + + Look for the most updated documentation on the Cocoon web site under + the Apache XML Project (http://xml.apache.org/cocoon/). + + + Licensing and legal issues + -------------------------- - Licensing - --------- + For legal and licensing issues, please read the LICENSE file. - Please see the file called LICENSE. - Acknowledgments - ---------------- + Thanks for using Cocoon. + The Apache XML Project + http://xml.apache.org/ + + \ No newline at end of file 1.1 xml-cocoon/changes.xml Index: changes.xml =================================================================== Removed all old PI formats from docs and properties file Added a public method to FormatterFactory to allow more direct formatting Patched EngineWrapper to allow FileProducer to work when called from command line.

Cocoon 1.5 - October 29, 1999
(Stefano Mazzocchi [SM], Donald Ball, Kenneth Murphy, Stefano Malimpensa [SM2])

  • Fixed concurrency problem in XML4j parser. Again thanks to Jeffrey Thomas Harris for the info (SM)
  • Added JRun installation instructions. Thanks to Scott Stirling for this (SM)
  • Added more info on the Cocoon status page. Thanks to David Lehn for the patch. (SM)
  • Patched OpenXML that had a bug in the XML publisher that didn't support doctypes imposed from the outside. This was breaking the WML formatter. (SM)
  • Patched XSL:P to support <xsl:processing-instruction> instead of <xsl:pi> which is now deprecated. This makes XSL:P a hybrid between XSLT revisions but it's easier this way than to create two sets of examples that work with latest and oldest releases of XSLT. Hopefully XSLT will standardize soon. (SM)
  • Fixed XML4J support bug. Thanks to Jeffrey Thomas Harris for the patch (SM)
  • Added XSL:P Formatters (SM)
  • Updated XSL:P to build 19991017 (SM)
  • Added parameter visibility to formatters to allow request-dependent formatting. Thanks to Ben Laurie for the suggestion (SM)
  • Changed Hashtable in more abstract Dictionary in all interfaces (this will be updated to collection classes when JDK 1.2 is available) (SM)
  • Updated Fop to version 0.11 (SM)
  • Added a work-around for the JServ1.1b2 bug (SM2)
  • Updated documentation (SM)
  • Added the plan for JavaDOC XML generator and the JavaDOC DTD working draft (KM)
  • Updated examples, especially the WML example which was based on an obsolete WML DTD (SM)
  • Added WML formatter (SM)
  • Added the ability to "mount" the Cocoon status to a configurable URL (SM)
  • Added the ability to hide Cocoon status for security reasons (SM)
  • Removed the persistent part of the object store since it's not used (SM)
  • Fixed DCP problem in loading the initScript.es file as system resource (SM)
  • Added some better diagnostic hooks. Thanks to Ben Laurie for the patch (SM)
  • Added SQLProcessor (DB)
  • Fixed a bug in the EcmaScript language interpreter.(SM2)
  • Fixed problems on startup without complete configurations and written more descriptive error messages on exceptions. (SM)
  • Updated the examples to reflect the changes. (SM)
  • Changed Cocoon illegal PIs from <?cocon:xxx?> to <?cocoon-xxx?>. Thanks to Tim Bray for his advice (SM)

Cocoon 1.4 - September 13 1999
(Stefano Mazzocchi, James Tauber, Paul O'Rorke, Ricardo Rocha, Christopher Conway, Keith Visco, Hannes Haug)

  • Fixed portability issues with JRun and Sun's JSWDK. (HH)
  • Added parsed stylesheets caching capabilities to the AbstractXSLTProcessor: now if produced files are changed but stylesheets don't, the second are not reparsed, improving the system performance since this is a very frequent case (SM) 
  • Reduced the memory footprint of some classes by initializing the hashtables to lower values than default (SM)
  • Improved the speed of PI searching by looking for first found PI instead of scanning the whole file (SM)
  • Updated the cocoon processing instructions that drive the reaction: <?cocoon:process?> drives the processing reaction, <?cocoon.format?> indicates the formatter used to end processing and format the document (SM)
  • Removed the processor pipeline and replaced with a reactor-type router with PI-based reaction. (SM)
  • Moved the example classes in their own package for easier installation and testing (SM) 
  • Modified a number of classes to fit the new Store and Cache subframeworks. (SM)
  • Added a first implementation of the Cache interface based on dynamic evaluation of changeable points. Since each page is created by different logic blocks, each one is treated as a changeable point and queried for change at request time. This allows the page to be recreated if one of the changeable points changes. (SM)
  • Added a first implementation of the Store interface based on serialization persistency wrapped by an adaptively managed memory buffer. The object storage system is used by the Cache system and its ready for long-living objects such as compiled pages and such that should survive the JVM shutdown. (SM)
  • Added support for the Oracle XSL Processor (works only with the Oracle XML Parser) (SM)
  • Added the Store framework (SM)
  • Included FOP Version 0.9.1 that partially supports latest XSL Formatting Object specification (19990421) (JT)
  • Included XSL:P Version 1.0 Beta (19990823) that supports latest XSLT specification (19990421) (KV)
  • Introduced the Actor/Director concept to allow cleaner implementation and configuration of dynamically loaded objects. (SM)
  • Added the WAP example to show how Cocoon can serve the same content to fat HTML clients and thin WML clients such as WAP-enabled cellular phones or PDA. (SM).
  • Removed the need for a properties file in DCP (SM)
  • Fixed a minor bug in Configurations. (HH)
  • Added the Producer subframework for easier dynamic XML generation (SM)
  • Rewrote and cleaned up the formatting section using the Router abstract class (SM)
  • Rewrote some of the underlying design pattern implementations (SM)
  • Fixed bug in SunXMLParser not implementing Status (CC)
  • Added support for Oracle XML parser (CC)
  • Added Dynamic Content Processor (RR)
  • Updated sample configurations to reflect the changes (SM)
  • Rewrote the PI parser for more general use in AbstractXSLProcessor (SM)
  • Created the EngineWrapper class to extend the Engine class for use on non-servlet based applications. (SM)
  • Added the possibility to use request parameters to trigger special events on the page. Currently debug and cache are supported (SM)
  • Added request and cache as parameters for the processor chain as requested by more sophisticated processors (SM)
  • Changed the cache system interface to match new needs (SM) [note: the cache system has not been yet ported]
  • Changed the printing architecture. Now, you don't need to specify the type of formattation but the publishing system will understand it for you (based on processing instructions and the specified document type) (SM)
  • Added white paper on the Cocoon 2 architecture for public review (SM)
  • Fixed typos, added support for more detailed verbosity and fixed a path-parsing bug for win32 systems (PO)
  • Added support for James Tauber's FOP to translate XSL:FO-styled documents into PDF documents (JT, SM)

Cocoon 1.3.1 - May 31 1999
(Donald Ball, Stefano Mazzocchi)

  • Added the first finished working draft of the XSP specification for public review (SM)
  • Removed the XML and XSL specifications from the distribution (SM)
  • Fixed a deadlock problem in the cache system (DB)

Cocoon 1.3 - May 12 1999
(Donald Ball, Stefano Mazzocchi, Robb Shecter)

  • Included more detailed example of future XSP technology (under examples/xsp). Note: the Cocoon 1.x generation will not support XSP and they are currently being designed. A very very early access of the working draft is available under docs/xsp (SM)
  • Patched the Sun ProjectX parser wrapper to work with latest release. Added also a Sun printer class (RS)
  • Added the ability to call Cocoon from the command line (DB and SM)
  • Fixed the final Vector.toString() problem in JDK 1.1 compilation (SM)
  • Fixed the "verify error" by using Jikes compiler for distribution (SM)
  • Cleaned up documentation and added some entries in the FAQ (SM)
  • Removed win32 batch scripts and rewritten the makefile (SM)
  • Added a better cache engine (DB)

Cocoon 1.2 - Apr 30 1999
(Stefano Mazzocchi, Donald Ball)

  • Improved documentation and cleaned things around (SM)
  • Changed versions of both OpenXML and XSL:P (SM)
  • Moved the core processing into a different class named Engine, first step to a complete servlet/application duality (SM)
  • Added the Cocoon status handler (SM)
  • Added a better user interface for the servlet and a nicer look to report errors (SM)
  • Added the OpenXML printer wrapper class that uses the new X3P API (DB)
  • Changed the initialization section to match exceptions thrown on different servlet platforms (SM).
  • Changed behavior to identity transformation through the DOM processors if no PI are found. Thanks to George T. Talbot for pointing it out (SM)

Cocoon 1.1.1 - Apr 5 1999
(Greg Ritter, Adrian Durkin, Stefano Mazzocchi)

  • Fixed a problem with the getClassloader() method returning null. Now Cocoon doesn't always use the internal properties file but adds hardcoded default values. This is because in Java 1.1 there is no getSystemClassloader() method (SM).
  • Included the updated versions of both OpenXML 1.0.5 and XSL:P 19990326 which should fix lots of bugs and improve the overall performance (SM)
  • Patched to avoid the use of File.toURL() method which is not found under the Java1 platform (SM, thanks to AD)
  • Added DoNothingCache to avoid caching during document debugging (GR)
Changed the stylesheet mapping processing instruction from illegal "xml:stylesheet" to standard "xml-stylesheet" Created Cocoon logo Added LRU caching (both memory and disk) Added support for XSL:P processor Removed support for Koala XSL parser Redesigned internal framework Fixed some typos and English bugs in docs Initial version 1.1 xml-cocoon/todo.xml Index: todo.xml =================================================================== Finish XML-ize the docs (changes.xml and faq.xml). Write the stylesheets for the docs. Add support for Xalan e Xerces and new FOP. support external entities with relative URIs pass request/session parameters to the XSLT processors for dynamic stylesheet operation Make sure you removed all the java.apache.org instances around. Play around with Tomcat. Add the Cocoon2 branch with the Kali sources. Add the XSP compiler. Write the NRG DTD WD and try to implement a formatter for this. (should we create its own project? include with FOP?) make the error page formatted with the wanted mime type and not only HTML (probably impossible in Cocoon1 model) Use Ant to build instead of makefile. From stefano@hyperreal.org Sat Nov 20 01:14:54 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 577 invoked by uid 2016); 20 Nov 1999 01:14:54 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 452 invoked by uid 218); 20 Nov 1999 01:14:16 -0000 Date: 20 Nov 1999 01:14:16 -0000 Message-ID: <19991120011416.451.qmail@hyperreal.org> From: stefano@hyperreal.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/docs/dtd - New directory stefano 99/11/19 17:14:14 xml-cocoon/docs/dtd - New directory From stefano@hyperreal.org Sat Nov 20 01:15:03 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 633 invoked by uid 2016); 20 Nov 1999 01:15:03 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 534 invoked by uid 218); 20 Nov 1999 01:14:33 -0000 Date: 20 Nov 1999 01:14:33 -0000 Message-ID: <19991120011433.533.qmail@hyperreal.org> From: stefano@hyperreal.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/docs/stylesheets - New directory stefano 99/11/19 17:14:31 xml-cocoon/docs/stylesheets - New directory From stefano@hyperreal.org Sat Nov 20 01:16:57 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 2723 invoked by uid 2016); 20 Nov 1999 01:16:57 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 2645 invoked by uid 218); 20 Nov 1999 01:16:55 -0000 Date: 20 Nov 1999 01:16:55 -0000 Message-ID: <19991120011655.2642.qmail@hyperreal.org> From: stefano@hyperreal.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/docs/stylesheets javadoc.html.css stefano 99/11/19 17:16:53 Added: docs cocoon2.xml dcpprocessor.xml dynamic.xml faq.xml guide.xml index.xml installing.xml license.xml sqlprocessor.xml technologies.xml docs/dtd blocks.ent changes.dtd characters.ent faq.dtd page.dtd todo.dtd docs/stylesheets javadoc.html.css Removed: docs api.html changes.html cocoon2.html dcp.html dynamic.html faq.html guide.html index.html installing.html license.html sqlprocessor.html stylesheet.css technologies.html todo.html Log: Cleaning up and moving to total XML docs Revision Changes Path 1.1 xml-cocoon/docs/cocoon2.xml Index: cocoon2.xml ===================================================================

The Cocoon Project has gone a long way since it's creation on January 1999. It started as a simple servlet for static XSL styling and became more and more powerful as new features were added. Unfortunately, design decisions made early in the project influenced its evolution. Today, some of those constraints that shaped the project were modified as XML standards have evolved and solidified. For this reason, those design decisions need to be reconsidered under this new light.

While Cocoon started as a small step in the direction of a new web publishing idea based on better design patterns and reviewed estimations of management issues, the technology used was not mature enough for tools to emerge. Today, most web engineers consider XML as the key for an improved web model and web site managers see XML as a way to reduce costs and ease production.

In an era where services rather than software will be key for economical success, a better and less expensive model for web publishing will be a winner, especially if based on open standards.

Web serving environments must be fast and scalable to be useful. Cocoon1 was born as a "proof of concept" rather than a production software and had significant design restrictions based mainly on the availability of freely redistributable tools. Other issues were lack of detailed knowledge on the APIs available as well as underestimation of the project success, being created as a way to learn XSL rather than a full publishing system capable of taking care of all XML web publishing needs.

For the above reasons, Cocoon1 was based on the DOM level 1 API which is a passive API and was intended mainly for client side operation. This is mainly due to the fact that most (if not all!) DOM implementations require the document to reside in memory. While this is practical for small documents and thus good for the "proof of concept" stage, it is now considered a main design constraint for Cocoon scalability.

Since the goal of Cocoon2 is the ability to process simultaneously multiple 100Mb documents in JVM with a few Mbs of heap size, careful memory use and tuning of internal components is a key issue. To reach this goal, an improved API model was needed. This is now identified in the SAX API which is, unlike DOM, event based (so active, in the sense that its design is based the inversion of control principle).

The event model allows document producers to trigger producing events that get handled in the various processing stages and get finally formatted in the response stream. This has significant impacts on performance and memory needs:

incremental operation: the response is created during document production. Client's perceived performance is dramatically improved since clients can start receiving data as soon as it is created, not after all processing stages have been performed. In those cases where incremental operation is not possible (for example, element sorting), internal buffers store the events until the operation can be performed. However, even in these cases performance can be increased with the use of tuned memory structures.

lowered memory consumption: since most of the server processing required in Cocoon is incremental, an incremental model allows XML production events to be transformed directly into output events and character written on streams, thus avoiding the need to store them in memory.

easier scalability: reduce memory needs allow more concurrent operation to be possible, thus allowing the publishing system to scale as the load increases.

more optimizable code model: modern virtual machines are based on the idea of hot spots, code fragments that are used often and, if optimized, increase the process execution by far. This new event model allows easier detection of hot spots since it's a method driven operation, rather than a memory driven one. Hot methods can be identified earlier and their optimization performed better.

reduced garbage collection: even the most advanced and lightweight DOM implementation require at least three to five times (and sometimes much more than this) more memory than original document size. This does not only reduce the scalability of the operation, but also impact overall performance by increasing the number of memory garbage that must be collected after the response in sent to the client. Even if modern virtual machines reduced the overhead of garbage collection, less garbage will always have performance and scalability impacts.

The above points, alone, would be enough for the Cocoon2 paradigm shift, even if this event based model impacts not only the general architecture of the publishing system but also its internal processing components such as XSLT processing and PDF formatting. These components will require substantial work and maybe design reconsideration to be able to follow a pure event-based model. The Cocoon Project will work closely with the other component projects to be able to influence their operation in this direction.

Another design choice that should be revised is the reactor pattern that was introduced to allow components to be connected in more flexible way. In fact, opposed to the fixed pipe model used up to Cocoon 1.3.1, the reactor approach allows components to be dynamically connected, depending on reaction instructions introduced inside the documents.

While this at first seemed a very advanced and highly appealing model, it turned out to be a very dangerous approach. The first concern is mainly technical: porting the reactor pattern under an event-based model requires limitations and tradeoffs since the generated events must be cached until a reaction instruction is encountered.

But even if the technical difficulties are solved, a key limitation remains: there is no single point of management.

The web was created to reduce information management costs by distributing them back on information owners. While this model is great for user communities (scientists, students, employees, or people in general) each of them managing small amount of personal information, it becomes impractical for highly centralized information systems where distributed management is simply not practical.

While in the HTML web model the page format and URL names where the only necessary contracts between individuals to create a world wide web, in more structured information systems the number of contracts increases by a significant factor due to the need of increased coherence between the hosted information: common style, common design issues, common languages, server side logic integration, data validation, etc...

It is only under this light that XML and its web model reveal their power: the HTML web model had too little contracts to be able to develop a structured and more coherent distributed information system, reason that is mainly imposed by the lack of good and algorithmically certain information indexing and knowledge seeking. Lacks that tend to degrade the quality of the truly distributed web in favor of more structured web sites (that based their improved site structure on internal contracts).

The simplification and engineering of web site management is considered one of the most important Cocoon2 goals. This is done mainly by technologically imposing a reduced number of contracts and place them in a hierarchical shape suitable to replace current high-structure web site management models.

The model that Cocoon2 adopts is the "pyramid model of web contracts" which is outlined in the picture below

and is composed by four different working contexts (the rectangles)

the people that decide what the site should contain, how it should behave and how it should appear the people responsible to write, own and manage the site content. This context may contain several sub-contexts one for each language used to express page content. the people responsible for integration with dynamic content generation technologies and database systems. the people responsible for information presentation, look & feel, site graphics and its maintenance.

and five contracts contexts (the lines)

management - content management - logic management - style content - logic content - style

The above model can be applied only if the different contexts never overlap, otherwise there is no chance of having a single management point. For example, if the W3C-recommended method to link stylesheets to XML documents is used, the content and style contexts overlap and it's impossible to change the styling behavior of the document without changing it. The same is true for the processing instructions used by the Cocoon1 reactor to drive the page processing: each stage concur to determine the result thus increasing management and debug complexity. Another overlapping in context contracts is the need for URL-encoded parameters to drive the page output. These overlaps break the pyramid model and increase the management costs.

In Cocoon2, the reactor pattern will be abandoned in favor of a chain mapping technique. This is based on the fact that the number of different contracts is limited even for big sites (for example, even if the pages are millions, they probably all share no more than a few different DTDs and each DTD has no more than a couple of stylesheets).

Also, for performance reasons, Cocoon2 will try to compile everything that is possibly compilable (pages/XSP into producers, stylesheets into processors, etc...) so, in this new model, the processing chain that generates the page contains (in a direct executable form) all the information/logic that handles the requested resource to generate its response.

This means that instead of using even-driven request-time DTD interpretation (done in all Cocoon1 processors), these will be either compiled into processors directly (XSLT stylesheet compilation) or compiled into producers using logicsheets and XSP which will remove totally the need for request-time interpretation solutions like DCP that will be removed.

The cache system in Cocoon1 will be ported with no important design changes since it's very flexible and was not polluted by early design constraints since it appeared in later versions. The issue regards static file caching that, no matter what, will always be slower than direct web server caching.

To be able to put most of the static part job back on the web server (where it belongs), Cocoon2 will greatly improve it's command line operation, allowing the creation of site makefiles that will automatically scan the web site and the source documents and will provide a way to regenerate the static part of a web site (images and tables included!) based on the same XML model used in the dynamic operation version.

It will be up to the web server administrator to use static regeneration capabilities on a time basis, manually or triggered by some particular event (database update signal) since Cocoon2 will only provide servlet and command line capabilities. The nice integration is based on the fact that there will be no behavioral difference if the files are dynamically generated in Cocoon2 via the servlet operation and cached internally or pre-generated and served directly by the web server, as long as URI contracts are kept the same by the system administrator (via URL-rewriting or aliasing)

Also, it will be possible to avoid on-fly page and stylesheet compilation (which make debugging harder) with command line pre-compilation hooks that will work like normal compilers from a developer's point of view.

Cocoon2 is a big and very ambitious project, not only for the technological issues involved (which will require strong integration with XML components) but also for the significant paradigm shifts imposed by the new technologies. On the other hand, we strongly believe this to be the winner model for future web engineering and if you believe in this yourself, we invite you to join us or help us in any way you can provide.

 1.1 xml-cocoon/docs/dcpprocessor.xml Index: dcpprocessor.xml ===================================================================

Yet to be XML-ized!

 1.1 xml-cocoon/docs/dynamic.xml Index: dynamic.xml ===================================================================

Web publishing is very limited without the ability to create dynamic content. For dynamic XML we refer to the content that is created as a function of request parameters or state of the requested resource. For this reason, a lot of work and design has been put into Cocoon to allow dynamic XML content to be generated.

People are used to write small Java programs to create their dynamic web content. Servlets, and Java in general, are very powerful, easy to write and fast to debug, but they impose (like any other pure-logic solution) a significant management cost. This is due to the fact that programmable components like servlets must include both the logic to generate the dynamic code as well as all static elements (such as static content and style).The need for a more useful solution soon appeared.

To fill the gap between Java programmers and web engineers (groups that rarely overlap), Sun proposed the Java Server Pages (JSP) specification, a markup language (today with both SGML and XML syntax) that allows web engineers to include code in their pages, rather than include pages in their code. The impact of this strategy was significant: servlets were written directly in Java code if very little static content was to be used, otherwise JSP or other compiled server pages technologies were used.

This said, it would seem that using servlets/JPS to create dynamic XML content would be the perfect choice, unfortunately design issues impose that we take a second look to the technology and understand why this isn't so.

Java Servlets were introduced by the Java Web Server team as a way to allow users to create their own web plug-ins. They were designed to handle the HTTP protocol and all possible dynamic web content (including HTML, XML, images, etc. both text and binary streams). Unfortunately, the need for a componentized request handler was not taken into serious consideration in the design phase but only later, when at an implementation phase.

In fact, the Java Web Server provided the ability to chain multiple servlets, one becoming the filter of the other. Unfortunately, since the API don't include such possibility in their design, such servlet chain is very limited in its behavior and poses significant restriction on the API use. Something that forced the Servlet API architects to come up with better solutions.

The solution was servlet nesting: the ability to include a servlet output inside its own transparently. This allowed programmers to separate different logic on different servlets, thus removing the need for servlet chaining

While servlet nesting was a major advantage over servlet chaining because it allowed servlets to be somewhat modular without loosing the full API power, a common design pattern applies to the Servlet model in general: no servlet is allowed to modify the output of another servlet. This holds true for all servlet API versions up to today (version 2.2).

This limitation is the key: if no further XML processing is needed on the server side, using servlets/JSP for creating XML is a perfect choice, but if this output requires some server side processing (for example XSLT transformations), the Servlet API does not allow another servlet to post process it's output. This other servlet is, in our case, Cocoon.

In a few words, the Servlet API doesn't support Servlet Piping.

Rather than turning Cocoon into a servlet engine, thus limiting its portability, this documents outlines some solutions that allow Cocoon users to get the servlet-equivalent functionality with internal Cocoon design ideas.

The Cocoon processing model is based on the separation of

where XML content is generated based on Request parameters (servlet equivalent) where the produced XML content is transformed/evaluated where the XML content is finally formatted into the wanted output format for client use.

This separation of working contexts allows Cocoon users to implement their own internal modules to add the functionality they require to the whole publishing system. In fact, while a few of these components are already shipped with Cocoon, the highly modular structure allows you to build your own to fit your particular needs.

Producers initiate the request handling phase. They are responsible to evaluate the HttpServletRequest parameters provided and create XML content that is fed into the processing reactor. A servlet logic should be translated into a producer if the request parameters can be used directly to generate the XML content (for example the FileProducer which loads the requested file from disk).

Here follows the code for an example producer distributed with Cocoon:

" + "" + "" + "

" + "Hello from a dummy page" + "

" + ""; public Reader getStream(HttpServletRequest request) throws IOException { return new StringReader(dummy); } public String getPath(HttpServletRequest request) { return ""; } public String getStatus() { return "Dummy Producer"; } } ]]>

The key method is getStream() which is responsible to create process the given servlet request and provide an output stream for reading the generated XML document.

Note that Produce has also another method, getDocument(request), which is responsible to return directly a DOM tree. In case you need to render you servlet code Cocoon-aware, the above example should tell you what to do.

Please, look at the shipped producers source code for example code and look at the user guide on how to install and use your own producers.

If your servlet needs many parameters to work, it is more reasonable that you write a Processor instead. A Processor transforms a given XML document (which, in this case should contain the needed static parameters) into something else, driven both by the input document and by the request object which is also available.

Here is a simple processor example that should show you what the above means. Suppose you have the following document as input (note that it may have been produced from a file, from other sources or dynamically, see the above paragraph):

Current time is

]]>

Our simple example processor will look for the %lg;time/%gt; tags and will expand them to the current local time, creating this result document:

Current time is 6:48PM

 ]]>

Please, look at the shipped processors source code for example code and look at the user guide on how to install and use your own processors.

The above example shows a very simple situation but needs non-trivial code to implement it. For this reason, the Cocoon distribution includes a number of processors that implement common needs and situations. These are:

the XSLT processor that applies XSLT transformations to the input document. XSLT allows you to solve your transformation needs as well as simple tag evaluation/processing due to its extensible and programmable nature. the DCP processor that evaluates XML processing instructions with multi-language (Java and EcmaScript) logic. This processor allows you to do programmatic substitution and inclusion eliminating the need for complex processing logic. See the DCP user guide for more information. the SQL processor that evaluates simple tags describing SQL queries to JDBC drivers and formats their result-set in XML depending on given parameters. See the SQL processor user guide for more information.

While the above represents a complete set of usable components for dynamic XML content generation, the Cocoon project aims to separate all three layers (content, logic and style). While XSLT transformations allow a perfect separation between content and style with the use of stylesheets, the separation between content and logic in dynamically generated XML pages is not achieved with current Cocoon features.

To fill this whole, the XSP (eXtensible Server Pages) technology was proposed. While in the working draft stage, we strongly believe that some of the issues expressed in that specification will be keys to the future of dynamic XML.

 1.1 xml-cocoon/docs/faq.xml Index: faq.xml =================================================================== I don't find my question answered here, what do I do?

First, checkout the Java Apache FAQ-O-Matic that contains a Cocoon section. You may find what you're looking for there. If not, you may consult the mail list digests and archives (we are aware of the problems regarding lack of searching capabilities in the mail list archive and, yes, we are trying to solve them). Then, if your problem is still unresolved, you should send a message describing your problem with very detailed information about your system, your status and your issues and asking for advice.

Please, keep in mind that nobody gets paid to answer your questions and be respectful of the time others are investing to answer you. Also, please, respect individual privacy and time by submitting help requests only to the mail lists and not directly to developers or individuals.

At the end, if you come up with a solution for your problem, please, don't throw away your effort, share it with us by directly adding it to the FAQ-O-Matic and post it to the mail list. Thanks.

How do I pipe my servlet output into Cocoon?

Simple answer: you don't!!! read this instead to find out equivalent ways to do what you need.

Complex answer: the Servlet API was not designed with servlet chaining capabilities in mind. Servlet chaining was a night hack of the original Java web server authors that allowed to pipe one servlet output into the request of another. Currently (version 2.2) the Servlet API spec doesn't allow a servlet to post-process the output of another servlet, so, since Cocoon is a servlet, there is no portable way for it  to call your servlet and  to process its output.

The Cocoon Project is in close contact with the Servlet API Expert Group at Sun (being Stefano Mazzocchi a member of that board) and will try to include post-processing hooks in the next Servlet API specifications. Since this is work in progress, please, don't fill up the mail list with questions about this: Cocoon will reflect the API changes as soon as they are publicly available.

 Where do I get more information on XSL and XML?

The web community is very exited about XML and XSL and many sources of information are coming up even if these languages are fairly new. Here is a list of locations you might be interested in to continue to gather resources on this state-of-the-art technology

 The XSL book I found says the correct way of indicating the XSL stylesheet is by using the XML processing instruction <?xml:stylesheet?> while Cocoon is using <?xml-stylesheet?>. Who is right?

The PI <?xml:stylesheet type="text/xsl" href=""?> is the old method of associating a stylesheet with an XML document. Unfortunately, this technology is rapidly changing and your books should warn you that the topic they are discussing is not even in W3C Recommendation state. Which means that more changes are on their way.

The current and proper way to associate a stylesheet with an XML document can be found at http://www.w3.org/TR/xml-stylesheet and clearly indicates that <?xml-stylesheet ...?> is the proper way.

 I think that using Processing Instructions to "chain" document layers somehow violates the context separation since I would like to be able to place style sensible information in sessions or request parameters. What do you think about this?

You are right, PI reaction breaks the context separation and it's, at the very end, the wrong approach. To follow a complete "model, view, controller" design pattern, one should be able to associate a different processing chain for each requested URI and for every possible request state (with request parameters, session parameters and environment parameters).

The proposed solution (as you read in the Cocoon2 outline) is to have a regular expression based site map where site managers decide what processing chain to apply to each possible request. This somehow follows the mod_rewrite model in the Apache Web Server, but rather than URL rewriting, the site map allows site designers to control the behavior of their documents in one place without having to modify every single reactive PI in each source file.

So, you've been warned: the PIs will go away, current functionality will remain but the processing management will be abstracted one layer up.

 What is WAP and I do I browse WML?

WAP stands for Wireless Application Protocol and WML stands for Wireless Markup Language. For more information about these two, please refer to the WAP Forum. For a client able to browse WML 1.1 look for the Nokia WAP Toolkit.

 When I compile Cocoon on my system, I get all a bunch of errors. What's wrong?

You probably didn't add all the needed packages to your compiler's classpath or used the wrong version of the servlet classes (Cocoon is compiled with the Servlet 2.1 classes). Note that Cocoon supports much more packages than you normally use and you should have them all to compile the full source code (this is why the cocoon.jar is distributed). To avoid this, simply remove (or rename) the classes that wrap around the packages you don't use.

Note that if you tried to compile Cocoon.java alone, many classes are not compiled because there is no hardcoded reference to them. Cocoon uses dynamic loading based on its property file to get the modules it needs when started. For this reason, the compiler is not able to tell which class will be use and its dependency checks are never complete. The only way to compile it is to manually indicate all the files to compile or to use the makefiles after removing the unwanted wrapper classes for the packages you don't have or you don't want.

External XML entities don't get included in my documents. What's wrong?

This is a well known bug in Cocoon. External entities don't work if not used in an absolute URL format, so you should either use an http:// or file:// URL with absolution location.

My stylesheet doesn't sense the presence of my request parameters. How do I pass them to it?

 Another well known bug. Cocoon is not yet able to pass request parameters to the stylesheets. It will be fixed in future releases.

 Why the name "Cocoon"?

(Cocoon's creator Stefano Mazzocchi answers): It's a pretty stupid reason and a funny story: I spent my 1998 Xmas vacation with my girlfriend up on the Alps at her cottage. One night, I couldn't sleep and I woke up to watch some TV and finishing reading the XSL documentation I brought with me. Being a science fiction afficionado, I found out that Ron Howard's movie Cocoon was on and I started watching it. The idea of the XSL rendering servlet stoke me like the alien "cocoons" in the pool stroke those old men in the movie and, while watching, I started paper-coding it right away. After a while the movie was over and the publishing framework designed. The name "Cocoon" seemed right for the thing, meaning to be a way to bring new life to old ideas as well as to create cocoons for such new ideas to become beautiful butterflies. :-)

 1.1 xml-cocoon/docs/guide.xml Index: guide.xml ===================================================================

This document assumes the knowledge of the W3C recommendation or working drafts used in Cocoon (mainly XML, XSL in both its transformation and formatting capabilities). This document is not intended to be an XML or XSL tutorial but just shows how these technologies may be used inside the Cocoon framework to create web content.

Cocoon is a publishing system that allows you to separate web development in three different layers: content, style and logic.

Cocoon does not aim to simplify the creation of web content: in fact, it is harder to create XML/XSL content than it is to use HTML from the beginning. So, if you are happy with the web technology you are using today, don't waste your time and stick with what you already have. Otherwise, if your troubles are site management, if your graphic people is always in the way, if you HTML authors always mess up your page logic, if your managers see no results in hiring new people to work on the site, go on and make your life easier.

This comment posted on the Cocoon mail list shows you what we mean:

I've got a site up and running that uses Cocoon. It rocks, the management loves me (they now treat me like I walk on water), and a couple of summer interns that I had helping me on the project are suddenly getting massively head-hunted by companies like AT&T now that they can put XML and XSL on their resumes. In a word: Cocoon simply rocks!

Every good user guide starts with an Hello World example and since we hope to write good documentation (even if its hard like hell!), we start from there too. Here is a well-formed XML file that uses a custom and simple DTD

Hello World! This is my first Cocoon page! ]]>

Even if this page mimics HTML (in a sense, HTML was born as a simple DTD for homepages), it is helpful to note that there is no style information and all the styling and graphic part is missing. Where do I put the title? How do I format the paragraph? How do I separated the content from the other elements? All these questions do not have answers because in this context they don't need one: this file should be created and maintained by people that don't need to be aware of how this content if further processed to become a served web document.

On the other hand, we need to indicate how the presentation questions will be answered. To do this, we must indicate a stylesheet that is able to indicate how to interpret the elements found in this document. Thus, we follow a W3C recommendation and add the XML processing instruction to map a stylesheet to a document:

]]>

Now that our content layer is done, we need to create a stylesheet to convert it to a format readable by our web clients. Since most available web clients use HTML as their lingua franca, we'll write a stylesheet to convert our XML in HTML (More precisely, we convert to XHTML which is the XML form of HTML, but we don't need to be that precise at this point).

Every valid stylesheet must start with the root element stylesheet and define its own namespace accordingly to the W3C directions. So the skeleton of your stylesheet is:

]]>

Once the skeleton is done, you must include your template elements, which are the basic unit of operation for the XSLT language. Each template is matched against the occurrence of some elements in the original document and the element is replaced with the children elements, if they belong to other namespaces, or, if they belong to the XSLT namespace, they are further processed in a recursive way.

Let's make an example: in our HelloWorld.xml document page is the root element. This must be transformed in all those tags that identify a good HTML page. Your template becomes:

<xsl:value-of select="title"/> ]]>

were some elements belong to the standard namespace (which we associate to HTML) and some others to the xsl: namespace. Here we find two of those XSLT elements: value-of and apply-templates. While the first searches the page element direct children for the title element and replace itself with the content of the retrieved element, the second indicates to the processor that should continue the processing of the other templates described in the stylesheets from that point.

Other possible templates are:

 ]]>

After the XSLT processing, the original document is transformed to

Hello

Hello

This is my first Cocoon page!

]]>

When a document is processed by an XSLT processor, its output is exactly the same for every browser that requested the page. Sometimes it's very helpful to be able to discriminate the client capabilities and transform content layer into different views/formats. This is extremely useful when we want to serve content do very different types of clients (fat clients like desktop workstations and thin clients like wireless PDAs) but we want to use the same informative source and create the smallest possible impact on the site management costs.

Cocoon is able to discriminate between browsers, allowing the different stylesheets to be applied. This is done by indicating in the stylesheet linking PI the media type, for example, continuing with the HelloWorld.xml document, these PIs

... ]]>

would tell Cocoon to apply the hello.text.xsl stylesheet if the Lynx browser is requesting the page. This powerful feature allows you to design your content independently and to choose its presentation depending on the capabilities of the browser agent.

The media type of each browser is evaluated by Cocoon at request time, based on their User-Agent http header information. Cocoon is preconfigured to handle these browsers:

any Microsoft Internet Explorer, searches for MSIE (before searching for Mozilla, since they include it too) the Opera browser (before searching for Mozilla, since they include it too) the text-only Lynx browser any Java code using standard URL classes the Nokia WAP Toolkit browser any Netscape Navigator, searches for Mozilla

but you can add your own by personalizing the cocoon.properties file modify the browser properties. For example

indicates that Cocoon should look for the token MSIE inside the User-Agent HTTP request header first, then Opera and so on, until Mozilla. If you want to recognize different generations of the same browser you should do find the specific string you should look for and indicate the order of searching since more browsers may contain the same string.

The Cocoon publishing system has an engine based on the reactor design pattern which is described in the picture below:

Let's describe the components that appear on the schema:

wraps around the client's request and contains all the information needed by the processing engine. The request must indicate what client generated the request, what URI is being requested and what producer should handle the request. is responsible of evaluating what processor should work on the document by reacting on XML processing instructions. The reactor pattern is different from a processing pipeline since it allows the processing path to the dynamically configurable and it increases performance since only those required processors are called to handle the document. The reactor is also responsible to forward the document to the appropriate formatter. transforms the memory representation of the XML document into a stream that may be interpreted by the requesting client. Depending on other processing instructions, the document leaves the reactor and gets formatted for its consumer. The output MIME type of the generated document depends on the formatter implementation. encapsulates the formatted document along with its properties (such as length, MIME type, etc..) is responsible of loading the formatted document when this is executable code. This part is used for compiled server pages where the separation of content and logic is merged and compiled into a Producer. When the formatter output is executable code, it is not sent back to the client directly, but it gets loaded and executed as a document producer. This guarantees both performance improvement (since the producer are cached) as well as easier producer development, following the common compiled server pages model. [this part is not yet implemented]

The Cocoon reactor uses XML processing instructions to forward the document to the right processor or formatter. These processing instructions are:

for processing and for formatting ]]>

These PIs are used to indicate the processing and formatting path that the document should follow to be served. In the example above, we didn't use them and Cocoon wouldn't know (rather than by the presence of the XSL PIs) that the document should be processed by the XSLT processor. To do this, the HelloWorld.xml document should be modified like this:

Hello World! This is my first Cocoon page! ]]>

The other processing instruction is used to indicate what formatter should be used to transform the document tree into a suitable form for the requesting client. For example, in the document below that uses the XSL formatting object DTD, the Cocoon PI indicates that this document should be formatted using the formatter associated to the text/xslfo document type.

Welcome to Cocoon ]]>

Cocoon comes with a number of processors and formatters which are configured as follows

type class Processors xslt org.apache.cocoon.processor.xslt.XSLPProcessor The XSLT Processor dcp org.apache.cocoon.processor.dcp.DCPProcessor The DCP Processor sql org.apache.cocoon.processor.sql.SQLProcessor The SQL Processor Formatters text/xml org.apache.cocoon.formatter.xml.OpenXMLXMLFormatter General XML Formatter text/html org.apache.cocoon.formatter.html.OpenXMLHTMLFormatter HTML 4.0 Formatter text/xhtml org.apache.cocoon.formatter.xhtml.OpenXMLXHTMLFormatter XHTML Formatter text/wml org.apache.cocoon.formatter.wml.OpenXMLWMLFormatter WML 1.1 Formatter text/xslfo org.apache.cocoon.formatter.pdf.FOPFormatter PDF Formatter

In a complex server environment like Cocoon, performance and memory usage are critical issues. Moreover, the processing requirement for both XML parsing, XSLT transformations, document processing and formatting are too heavy even for the lightest serving environment based on the fastest virtual machine. For this reason, a special cache system was designed underneath the Cocoon engine and its able to cache both static and dynamically created pages.

Its operation is simple but rather powerful:

when the request comes, the cache is searched. if the request is found; its changeable points are evaluated if all changeable points are unchanged the page is served directly from the cache if a single point has changed and requires reprocessing the page is invalidated and continues as if it wasn't found if the request is not found: the page is normally processed it's sent to the client it's stored into the cache

This special cache system is required since the page is processed with the help of many components which, independently, may change over time. For example, a stylesheet or a file template may be updated on disk. Every processing logic that may change its behavior over time it's considered changeable and checked at request time for change.

Each changeable point is queried at request time and it's up to the implementation to provide a fast method to check if the stored page is still valid. This allows even dynamically generated pages (for example, an XML template page created by querying a database) to be cached and, assuming that request frequency is higher than the resource changes, it greatly reduces the total server load.

Moreover, the cache system is based on a persistent object storage system which is able to save stored objects in a persistent state that outlives the JVM execution. This is mainly used for pages that are very expensive to generate and last very long without changes, such as compiled server pages. [this part is not yet implemented]

The store system is responsible of handling the cached pages as well as the pre-parsed XML documents. This is mostly used by XSLT processors which store their stylesheets in a pre-parsed form to speed up execution in those cases where the original file has changed, but the stylesheet has not (which is a rather frequent case).

 1.1 xml-cocoon/docs/index.xml Index: index.xml ===================================================================

Cocoon is a 100% pure Java publishing framework that relies on new W3C technologies (such as DOM, XML, and XSL) to provide web content.

The Cocoon project aims to change the way web information is created, rendered and served. This new paradigm is based on fact that document content, style and logic are often created by different individuals or working groups. Cocoon aims to a complete separation of the three layers, allowing the three layers to be independently designed, created and managed, reducing management overhead, increasing work reuse and reducing time to market.

Read the Introduction on Cocoon technologies white paper to find out more on the subject.

Web content generation is mostly based on HTML, but HTML doesn't separate the information from its presentation, mixing formatting tags, descriptive tags and programmable logic (both on server side and client side). Cocoon changes this view allowing content, logic and style on different XML files and uses XSL transformation capabilities to merge them.

Even if the most common use of Cocoon is the automatic creation of HTML through the processing of statically or dynamically generated XML files, Cocoon is also able to perform more sophisticated formatting, such as XSL:FO rendering on PDF, client-depending transformations such as WML formatting for WAP-enabled devices or direct XML serving to XML and XSL aware clients.

The Cocoon model allows web sites to be highly structured and well designed, reducing duplication efforts and site management costs by allowing different presentations of the same data depending on the requesting client (HTML clients, PDF clients, WML clients) and separating on different contexts different requirements, skills and capacities. Cocoon allows a better human resource management by giving to each individual its job and reducing to a minimum the cross-talks between different working contexts.

To do this, the Cocoon model divides the development of web content in three separate levels: the XML file is created by the content owners. They do not require specific knowledge on how the XML content is further processed rather than the particular chosen DTD/namespace. This layer is always performed by humans directly through normal text editors or XML-aware tools/editors. the requested XML file is processed and the logic contained in its logicsheet is applied. Unlike other dynamic content generators, the logic is separated from the content file. the created document is then rendered by applying an XSL stylesheet to it and formatting it to the specified resource type (HTML, PDF, XML, WML, XHTML)

The biggest known problem in this framework is the lack of XML/XSL knowledge, being relatively new formats. We do believe, though, that this publishing framework will be a winner in web sites of medium to high complexity and will lead the transition from an HTML-oriented to a XML-oriented web publishing model, still allowing the use of existing client technologies as well as supporting new types of clients (such as WAP-aware ultra thin clients like cell phones or PDAs).

Even if considered heavy and hype overloaded, the XML/XSL pair will do magic once its public knowledge receives the spread it deserves. This project wants to be a small step in this direction, helping people to learn this technology and to focus on what they need with examples, tutorial and source code and a real-life system carefully designed with portability, modularity and real-life usage in mind.

The main concern remains processing complexity: the kind of operations required to process the document layers are complex and not designed for real-time operation on the server side. For this reason, Cocoon is designed to be a page compiler for dynamic pages, trying to hardcode, whenever possible, those layers in precompiled binary code coupled with an adaptive and memory-wise cache system for both static and dynamic pages. Most of the development effort is focused on performance improvement of both processing subsystems as well as the creation and testing of special cache systems.

In this direction it must be understood that Cocoon 1.x should be considered a proof of concept rather than a software usable for real web sites. In fact, the Cocoon projects aims to gather as much information as possible during it's first generation while its second generation, starting from Cocoon 2.0, will aim to be a usable and real-life publishing framework. See the Cocoon 2 outline to understand the design plans already established.

Another problem is the intrinsic impossibility of page-compiling all the three processing layers, due to the post-processing requirements of XSL styling. This problem will be solved (hopefully!) with the availability of XSL-enabled web browsers since the XSL rendering would be then performed on client side reducing the server work.

Go to the download area and be sure you read the release note in that page.

The Cocoon Project is an open volunteer project based on the spirit of the Apache Software Foundation (ASF). This means that there are lots of ways to contribute to the project, either with direct participation (coding, documenting, answering questions, proposing ideas, reporting bugs, suggesting bug-fixes, etc..) or by resource donation (money, time, publicity, hardware, software, conference presentations, speeches, etc...).

For direct participation, we suggest you to subscribe to the Cocoon mail list (follow the link for information on how to subscribe and to access the mail list archives), to checkout the latest and greatest code (which you found in the xml-cocoon module in the xml.apache.org CVS code repository), control the todo list and jump in. Document writers are usually the most wanted people so if you like to help but you're not familiar with technical details, don't worry we have work for you.

For money funding in particular, the Cocoon Project and the ASF in general is closely collaborating with the Collab.net SourceXchange program that will provide a legal, solid and well established resource for money collecting to fund direct software production under the open source flag. Please, feel free to contact directly Cocoon's main architect and project creator Stefano Mazzocchi or the ASF President and Collab.net co-founder Brian Behlendorf for more information on how to contribute directly to the advancement of this project.

Anyway, a great way of contributing back to the project is to allow others to know about it so that the word spreads and other may wish to contribute, so, please, help us by placing the cocoon logo somewhere in your site to indicate that you are using uses and supporting the Cocoon Project.

Thank you very much.

1.1 xml-cocoon/docs/installing.xml Index: installing.xml ===================================================================

Cocoon requires the following systems to be already installed in your system:

A Java 1.1 or greater compatible virtual machine must be present for both command line and servlet type usage of Cocoon. Note that all servlet engines require a JVM to run so if you are already using servlets you already have one installed. A Servlet 2.x compliant servlet engine must be present in order to support servlet operation and dynamic request handling. Note that this requirement is optional for command line operation.

Cocoon is a publishing framework and was designed to be highly modular to allow users to choose their preferred implementation for the required component and to allow better and faster parallel development.

Cocoon uses an XML parser and an XSLT processor has its basic components and uses the DOM API to access work with them. For this reason, you need both DOM-enabled XML parser and XSLT processor. Also, for complex formatting, Cocoon uses a formatting object renderer and a set of printing classes to send the page to the client.

Being an Apache project, Cocoon focues on Apache technologies and comes configured to operate with Xerces, Xalan and FOP, but other DOM-aware components are supported as well (see the cocoon.properties file for more information on other components supported).

For this reason, in order to work out of the box and have complete operation, you need to download all three packages (Xerces-J, Xalan-J and FOP) from the xml.apache.org. Once you have all three jar packages required and all other packages that may be required by these projects, go ahead and follow the instructions for your servlet engine.

Being Cocoon a servlet, you should be able to install it on every compliant servlet engine by associating the "org.apache.cocoon.Cocoon" servlet with the requests you want it to handle. In order to do this, there is no standard way, so we try to provide detailed information for the most used servlet systems.

Apache JServ has one configuration file for the whole engine (normally called jserv.properties) and one for each servlet zone. Please, refer to the Apache JServ documentation for more information on this.

First thing to do is to make sure that the components needed by Cocoon (and explained in the above paragraphs) are visible. This implies adding this to the servlet engine classpath by adding a line like this in your jserv.properties file for each jar package you have to install after substituting [path-to-jar] with the path to the jar file and [jar-name] with the package file name.

wrapper.classpath=[path-to-jar]/[jar-name].jar

Note: do not add the cocoon.jar package here since this might corrupt it's normal operation. Here, you should add all the required packages but Cocoon itself.

At this point, you must tell the servlet engine to locate Cocoon (since you didn't do this in the step right above!). To do this, you should choose the servlet zone where you want Cocoon to reside. If you don't know what a servlet zone is, you probably want to open the zone.properties file that represents the default servlet zone. Now add the cocoon.jar package to your servlet zone by making sure a line like this is present in your zone property file.

repositories=...,[path-to-cocoon]/bin/cocoon.jar

where ... stands for any other servlet repository the servlet zone already contains (or might be empty if no other repository is used by this zone) and [path-to-cocoon] is substitued by the actual path to the cocoon.jar file.

Now the servlet engine knows where to locate the Cocoon servlet but Cocoon must need to know its configurations to be able to start. To configure Cocoon, you must pass the cocoon.properties file location to the servlet by adding the following to the zone.properties file:

servlet.org.apache.cocoon.Cocoon.initArgs=properties=[path-to-cocoon]/bin/cocoon.properties

Note that you should not need to change anything from the template properties file found in the distribution, but you must edit it for more complex operation. Please refer directly to the file that contains breaf indications and comments on the different configurations, but you don't need to care about that at this point.

Now your cocoon servlet is properly configured, but you should tell Apache to direct any call to an XML file (or any other file you want Cocoon to process) to the Cocoon servlet. To do this, you should add the following line to your mod_jserv.conf or jserv.conf file:

ApJServAction .xml /servlet/org.apache.cocoon.Cocoon

where .xml is the file extention you want to map to the servlet and /servlet/ is the mount point of your servlet zone (and the above is the standard name for servlet mapping for Apache JServ).

>

Everything should be configured fine. Restart both Apache and Apache JServ and try accessing the samples contained in the distribution to see Cocoon in action.

Yet to be written! Volunteers welcome!

Yet to be written! Volunteers welcome!

Yet to be written! Volunteers welcome!

Cocoon has been reported to be working on these systems:

RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.8 RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.8 RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + Blackdown JDK 1.2pre2 RedHat Linux 6.1 + Apache 1.3.9 + JRun 2.3.3 + IBM JRE 1.1.8 Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.7 Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.7 Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + Sun JDK 1.2.2 Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.2.2 Windows 98 + MS Personal Web Server + ServletExec 2.2 + Sun JDK 1.2.1 Windows NT 4.0 + IIS 4.0 + ServletExec 2.2 + Sun JDK 1.2.1 Windows NT 4.0 + IIS 4.0 + JRun 2.3.3 + Sun JDK 1.2.1 MacOS 8.6 + WebSTAR 4.0 + JRun 2.3 + MrJ 2.1.4 MacOS 8.6 + WebSTAR 4.0 + ServletExec 2.1 + Mrj 2.1.4 SunOS Netria 5.6 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.1.7

Note: due to a bug in Blackdown JDK 1.2pre2 for Linux, we suggest you to use green threads instead of the native ones which are much less stable, expecially highly concurrent operations like servlet engines and servlet execution.

Please, submit your feedback if you were able to install Cocoon on a different combination not listed above. Thanks.

1.1 xml-cocoon/docs/license.xml Index: license.xml ===================================================================
. For more information on the Apache Software Foundation, please see . ]]>
1.1 xml-cocoon/docs/sqlprocessor.xml Index: sqlprocessor.xml ===================================================================

Yet to be XML-ized!

 1.1 xml-cocoon/docs/technologies.xml Index: technologies.xml ===================================================================

Many people do not seem to understand the global picture about the technologies used by Cocoon, I will try to explain my vision of these technologies as well as some information that might be useful to you to jump in, help with its development or show your boss how much money he can save.

XML (eXtended Markup Language) is an SGML subset. SGML is the father of all markup languages and its a 15-years old ISO standard for creating languages. XML is a lighter version of SGML.

First thing to understand: XML is NOT a language (like HTML), but a syntax. Exactly like ASCII that defines a standard way to map characters to bytes and not a bunch of character strings.

XML is usually referred to as "portable data" in the sense that its parsing is "application independent" and one XML parser can read every possible XML document, one describing your bank account, another describing your favorite Italian meal, etc. This is, as you all know, impossible with other file formats which are text based or binary. Some sort of equivalent in the old days are CSV (comma separated values) files which use a very simple syntax (use comma to separate values and the first raw to outline the content of the columns) and are portable to every implementation. XML, unlike CSV, is much more flexible and structured even if it's much simpler than SGML.

A particular XML language is defined by its Document Type Definition (DTD) which is described inside the XML specification. An XML document may be validated against a DTD (if present) and if the validation is successful the document is said "valid XML based on the particular DTD", if a DTD is not present and the parser does not encounter syntax errors parsing the file, the XML document is said "well-formed". If errors are found, the document is not XML compliant.

So, any valid XML document is well-formed and an XML document valid for one particular DTD may not necessary be valid for another DTD. For example, HTML is not an XML language because the <br> tag is not XML compliant. XHTML (where <br> is replaced by <br/>) is XML compliant. While HTML pages are not always XML documents (some pages might be), XHTML pages are always well-formed and valid if matched against the XHTML DTD.

So far for the technical differences, but why HTML was not good enough? Let's make an example.

Consider why the need for XML came about:

Everyone starts pubitemshing HTML documents on the web. Search engines spring up across the net to help find documents. Search engines have a difficult time searching specific pieces of a document since HTML was designed to hierarchically represent how data should be presented, but not what the data being presented is. Web appitemcations spring up across the net to provide information and "services".

These services could be web pages that serve up important information about an organization or the structure of the organization. They could be weather information, or travel advisories. They could be contact information for people. Stock quotes. It could a book on how to grow the perfect Tomato.

So now we have all this information. Tons of it. Great! Now go and search all these web pages for specific content, like Author or Subject. Find me all abstracts of any documents published that have a subject of "Big Tomatoes", since I only want to view abstracts to find out which document is best for me. An HTML page is not designed for this. It was designed for how to present the data.

When I look at a web page I might see that an author choose to make every paragraph heading bold with <font size+1>. Yet if I look at another page I might notice that every paragraph heading was marked up with <H1>. Yet another page may use tables and table headers to format the data. Find me every document that has the word "potato" in the paragraph heading of the first paragraph.

Suppose I have a weather web-based application that servers up weather information for different parts of the country. Let's say you live in Boston, MA and only want the weather for Boston. Your boss asks you to write an application that goes out and grabs the two-three sentence weather summary from my application and display this on your intranet's homepage.

You take a quick jaunt over to my weather application and notice that the summary is in what looks like the second paragraph of the page. So you take a quick peek at the HTML source that my weather application returned. You suddenly realize that it's all on one line, and is buried deep within tables.

So you start writing your little application that parses my HTML code to retrieve just the information you were looking for. You pat yourself on the back when 4 hours later you finally get the information you were look for. Your code looks for the 2nd Table, the 6th TR and then the 2nd TD. Phew. Your application, that only wants weather data, is forced to parse display markup to get the data it needs.

You run over to your boss and show him your application that you are so proud that you wrote. Low and behold it doesn't work. What happened? Good old path author decided to change his display and put the weather summary in Table 1, TR 1, TD 1. Your application broke because it was tied to the presentation of the data and not to the data itself. Not very effective. Since now your app will break every time the page author drinks too much coffee.

Then you notice, something on the page that interests you. This site was automatically generated from XML and you see a link that says XML DTD for weather information. And another link that says XML stream for weather information available. Yikes, would you look at that:

Boston MA Beautiful and Sunny, lows 50, highs 65, with the chance of a blizzard and gail force winds. ]]>

So you download Cocoon, simply write an XSL stylesheet that looks the the following:

... presentation info here ... ]]>

And your boss gives you your job back! ;-)

As the above example explains very well, HTML is a language for describing graphics, behavior and hyperlinks on web pages. HTML is NOT able to contextualize (means "give meaning to some text") in the sense that if you look for the "title" of your page, a nice HTML tag gives you that, but if you look at the author or version or something more specific like the author mail address, even if this information is present in the text you don't have a way to "isolate" this (contextualize it) from the surrounding information.

In some HTML like this

This is my article

This is my article

Stefano Mazzocchi

... ]]>

you don't have a guaranteed way to extract the mail address, while in the following XML document

This is my article Stefano Mazzocchi stefano@apache.org ... ]]>

it's trivial and algorithmically certain.

We don't picture XML take over HTML in web publishing since HTML is great for small needs. HTML was born as an SGML-based DTD for scientists homepages. HTML was NOT designed for publishing and treatment of large quantity of data and complex dynamic information systems, but only to parallelize and simplify the deployment and management of personal information.

As you see, XML alone is useless without some defined semantics: even if an application is able to parse a document in memory, it must be able to understand that the markup means. This is why XML-only browsers are meaningless and not more useful than text editors from an usability point of view.

This is one of the reasons why the XSL language (eXtensible Stylesheet Language) was proposed and designed. XSL is divided in two parts: transformation (XSLT) and formatting objects (sometimes referred to FO, XSL:FO or simply XSL). Both are XML DTDs that define a particular XML syntax. So every XSL and XSLT document is a well-formed XML document.

XSLT is a language for transforming one well-formed XML document into something else. This means that you may use it to go from one DTD to another in an procedural way that is defined inside your XSLT document. Even if the name tells the opposite, this language can be used for document styling as well as for many other useful transformations: in fact, transformations may be applied to one particular XML DTD and come up with some "graphical description" of the original content. This is called "styling", but, as you can see, this is just one of the possible uses of the technology.

For example, the above HTML example may be created from the second XML file given a particular transformation sheet (which in this case becomes a stylesheet). As you can see, the data is all there: we just have to tell the transformer how to come up with the HTML document once all the data is parsed in memory.

Usually, transformation sheets work from one DTD to another and for this reason may be used in chain: transformA goes from DTD1 to DTD2 and transformB from DTD2 to DTD3 or graphically

DTD1 ---(transformA)--> DTD2 ---(transformB)---> DTD3

We'll call DTD1 the original DTD (because its the origin), DTD2 some intermediate DTD, DTD3 the final DTD. It can be shown that a transformation can always be created to go directly from DTD1 to DTD3, but this might be more complicated and less human readable/manageable.

XSLFO is a language (an XML DTD) for describing 2D graphics of text in both printed and digital media. I will not concentrate on the graphical abilities that formatting objects gives you, but rather on the fact that it is most of the time used as a "final DTD", meaning that a transformation is used to generate a formatting object description of a document starting from a general XML file.

The example above would lead:

... This is my article by Stefano Mazzocchi ]]>

which tells the formatting object formatter (the rendering engine), how to "draw" and place the text on the screen or on paper. Formatting objects and transformations are created by the same working group and show very high synergies even if the XSLT specification also includes way to create HTML and text out of XML files as well.

The Cocoon publishing model is heavily based on the XSLT transformation capabilities that allow complete separation of content and style (something that is much harder to obtain with HTML even using CSS2 or other styling technologies) but it moved on to defined a way to separate page content and document tags from the programming logic that drive their server side behavior.

The XSP language (eXtensible Server Pages) languages defines an XML DTD for separating content and logic for compiled server pages. XSP (eXtensible Server Pages) is, like XSLFO, supposed to be a "final DTD" in the sense that is the result of one or more transformation steps and must be rendered by some formatter into pure source code that can then be compiled into binary code.

In every dynamic page, there is a mix of static content and logic that work together to create the final result, usually using run-time or time-dependent input. In dynamic content generation technology, content and logic are mixed in the same page. XSP is no exception since it defines a syntax to mix static content and programmatic logic in a way that is independent of the programming language used and on the binary results that the final source-rendering gives.

But it must be understood that XSP is just a piece of the framework: exactly like formatting objects mix style and content, XSP mix logic and content. On the other hand, being both XML DTDs, XSLT can be used to move from pure content to these final DTDs, placing the style and logic on the transformation layers and guaranteeing complete separation and easier maintenance.

 1.1 xml-cocoon/docs/dtd/blocks.ent Index: blocks.ent =================================================================== %charEntity; 1.1 xml-cocoon/docs/dtd/changes.dtd Index: changes.dtd =================================================================== %blocksEntity; 1.1 xml-cocoon/docs/dtd/characters.ent Index: characters.ent =================================================================== 1.1 xml-cocoon/docs/dtd/faq.dtd Index: faq.dtd =================================================================== %blocksEntity; 1.1 xml-cocoon/docs/dtd/page.dtd Index: page.dtd =================================================================== %blocksEntity; 1.1 xml-cocoon/docs/dtd/todo.dtd Index: todo.dtd =================================================================== %blocksEntity; 1.1 xml-cocoon/docs/stylesheets/javadoc.html.css Index: javadoc.html.css =================================================================== /* Apache Javadoc style sheet */ /* Page background color */ body { background-color: #FFFFFF } /* Table colors */ .TableHeadingColor { background: #D0D0D0 } .TableSubHeadingColor { background: #E0E0E0 } .TableRowColor { background: #F9F9F9 } /* Navigation bar fonts and colors */ .NavBarCell1 { background-color:#D0D0D0;} .NavBarCell1Rev { background-color:#A0A0A0;} .NavBarFont1 { font-family: Arial, Helvetica, sans-serif; color:#000000;} .NavBarFont1Rev { font-family: Arial, Helvetica, sans-serif; color:#FFFFFF;} .NavBarCell2 { font-family: Arial, Helvetica, sans-serif; background-color:#E0E0E0;} .NavBarCell3 { font-family: Arial, Helvetica, sans-serif; background-color:#F0F0F0;} /* Font used in left-hand frame lists */ .FrameTitleFont { font-size: normal; font-family: Helvetica, Arial, sans-serif } .FrameHeadingFont { font-size: normal; font-family: Helvetica, Arial, sans-serif } .FrameItemFont { font-size: 10pt; font-family: Helvetica, Arial, sans-serif } /* Link colors styling */ A:link { color: #0000A0 } /* unvisited link */ A:visited { color: #A00000 } /* visited links */ A:active { color: #00A000 } /* active links */ From stefano@hyperreal.org Sat Nov 20 01:18:49 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 5332 invoked by uid 2016); 20 Nov 1999 01:18:49 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 5323 invoked by uid 218); 20 Nov 1999 01:18:44 -0000 Date: 20 Nov 1999 01:18:44 -0000 Message-ID: <19991120011844.5322.qmail@hyperreal.org> From: stefano@hyperreal.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/samples/xsp sample.xml sample.xsl snoop.xml view-source.xml page.xml README stefano 99/11/19 17:18:44 Modified: samples/xsp page.xml Added: samples/xsp sample.xml sample.xsl snoop.xml view-source.xml Removed: samples/xsp README Log: Added other XSP examples now that XSP is on its way Revision Changes Path 1.2 +3 -4 xml-cocoon/samples/xsp/page.xml Index: page.xml =================================================================== RCS file: /home/cvs/xml-cocoon/samples/xsp/page.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- page.xml 1999/11/09 01:51:35 1.1 +++ page.xml 1999/11/20 01:18:38 1.2 @@ -3,19 +3,18 @@ - First Page + First XSP Page Stefano Mazzocchi
stefano@apache.org
 - $Id: page.xml,v 1.1 1999/11/09 01:51:35 stefano Exp $ + $Id: page.xml,v 1.2 1999/11/20 01:18:38 stefano Exp $

Hi, I'm the first XSP page ever.

This page is an example of usage for XSP technology which is being designed to add dynamic XML capabilities to the Cocoon publishing - framework. Note: Cocoon will not be able to work with XSP pages - until its second generation, starting from Cocoon 2.0

+ framework.

In this page, the content is automatically generated by translating this template page into some source code (Java in this case) and then executed 1.1 xml-cocoon/samples/xsp/sample.xml Index: sample.xml =================================================================== A Simple XSP Page

Hi, I've been hit times.

Source Code

1.1 xml-cocoon/samples/xsp/sample.xsl Index: sample.xsl =================================================================== <xsl:value-of select="title"/>

1.1 xml-cocoon/samples/xsp/snoop.xml Index: snoop.xml =================================================================== Snoop XSP Page

  • Parameter values (try your own!)

    Enumeration enum = request.getParameterNames(); while (enum.hasMoreElements()) { String parameterName = (String) enum.nextElement(); String[] parameterValues = request.getParameterValues(parameterName); }
    Name Value(s)
    parameterName for (int i = 0; i < parameterValues.length; i++) { parameterValues[i]
    }

  • Request Attributes:

    Protocol request.getProtocol()
    Scheme request.getScheme()
    Server Name request.getServerName()
    Server Port request.getServerPort()
    Remote Address request.getRemoteAddr()
    Remote Host request.getRemoteHost() 
    Character Encoding request.getCharacterEncoding() 
    Content Length request.getContentLength() 
    Content Type request.getContentType() 
    Servlet Path request.getServletPath() 
    Request URI request.getRequestURI() 
    Path Translated request.getPathTranslated() 
    Path Info request.getPathInfo() 

Source Code

1.1 xml-cocoon/samples/xsp/view-source.xml Index: view-source.xml =================================================================== private static final String ATTR_NAME_COLOR = "brown"; private static final String ATTR_VALUE_COLOR = "magenta"; private static final String COMMENT_COLOR = "gray"; private static final String DELIMITER_COLOR = "green"; private static final String ELEMENT_COLOR = "darkBrown"; private static final String ENTITY_REF_COLOR = "navy"; private static final String PI_DATA_COLOR = "lightBlue"; private static final String TEXT_COLOR = "black"; private static final String CUSTOM_ELEMENT_COLOR = "purple"; private static final String XSL_ELEMENT_COLOR = "navy"; private static final String XSP_ELEMENT_COLOR = "red"; private static final String XSP_TEXT_COLOR = "blue"; protected Element colorize(Node node, Document factory) { Element element = factory.createElement("pre"); DocumentFragment fragment = factory.createDocumentFragment(); element.appendChild(doColorize(node, factory, 0)); return element; } protected static DocumentFragment doColorize(Node node, Document factory, int level) { Element result = null; DocumentFragment fragment = factory.createDocumentFragment(); switch (node.getNodeType()) { case Node.CDATA_SECTION_NODE: result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("<")); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", ELEMENT_COLOR); result.appendChild(factory.createTextNode("![CDATA[")); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", ATTR_VALUE_COLOR); result.appendChild(factory.createTextNode(node.getNodeValue())); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", ELEMENT_COLOR); result.appendChild(factory.createTextNode("]]")); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("<")); fragment.appendChild(result); break; case Node.ELEMENT_NODE: { Element element = (Element) node; result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("<")); fragment.appendChild(result); String tagColor = ELEMENT_COLOR; String tagName = element.getTagName(); if (tagName.startsWith("xsp:")) { tagColor = XSP_ELEMENT_COLOR; } else if (tagName.startsWith("xsl:")) { tagColor = XSL_ELEMENT_COLOR; } else if (tagName.indexOf(':') >= 0) { tagColor = CUSTOM_ELEMENT_COLOR; } result = factory.createElement("font"); result.setAttribute("color", tagColor); result.appendChild(factory.createTextNode(tagName)); fragment.appendChild(result); NamedNodeMap attributes = element.getAttributes(); int attributeCount = attributes.getLength(); for (int i = 0; i < attributeCount; i++) { Attr attribute = (Attr) attributes.item(i); result = factory.createElement("font"); result.setAttribute("color", ATTR_NAME_COLOR); result.appendChild( factory.createTextNode(" " + attribute.getName() + "=") ); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", ATTR_VALUE_COLOR); result.appendChild( factory.createTextNode("\"" + attribute.getValue() + "\"") ); fragment.appendChild(result); } NodeList nodeList = element.getChildNodes(); int childCount = nodeList.getLength(); result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode((childCount == 0 ? "/" : "") + ">")); fragment.appendChild(result); String textColor = TEXT_COLOR; if (tagName.startsWith("xsp:")) { textColor = XSP_TEXT_COLOR; } result = factory.createElement("font"); result.setAttribute("color", textColor); for (int i = 0; i < childCount; i++) { result.appendChild( doColorize(nodeList.item(i), factory, level + 1) ); } fragment.appendChild(result); if (childCount > 0) { result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("</")); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", tagColor); result.appendChild(factory.createTextNode(tagName)); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode(">")); fragment.appendChild(result); } break; } case Node.DOCUMENT_NODE: case Node.DOCUMENT_FRAGMENT_NODE: { NodeList nodeList = node.getChildNodes(); int childCount = nodeList.getLength(); for (int i = 0; i < childCount; i++) { fragment.appendChild( doColorize(nodeList.item(i), factory, level + 1) ); } break; } case Node.COMMENT_NODE: result = factory.createElement("font"); result.setAttribute("color", COMMENT_COLOR); result.appendChild( factory.createTextNode( "<!-- " + node.getNodeValue() + " -->" ) ); fragment.appendChild(result); break; case Node.PROCESSING_INSTRUCTION_NODE: ProcessingInstruction pi = (ProcessingInstruction) node; result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("<?")); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", ATTR_NAME_COLOR); result.appendChild(factory.createTextNode(pi.getTarget())); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", PI_DATA_COLOR); result.appendChild(factory.createTextNode(" " + pi.getData())); fragment.appendChild(result); result = factory.createElement("font"); result.setAttribute("color", DELIMITER_COLOR); result.appendChild(factory.createTextNode("?>\n")); fragment.appendChild(result); break; case Node.ENTITY_REFERENCE_NODE: result = factory.createElement("font"); result.setAttribute("color", ENTITY_REF_COLOR); result.appendChild(factory.createTextNode("<" + node.getNodeValue() + ";")); fragment.appendChild(result); break; case Node.TEXT_NODE: fragment.appendChild(factory.createTextNode(node.getNodeValue())); break; default: break; } return fragment; } Source Code String filename = request.getParameter("filename");

filename

this.colorize( this.xspParser.parse ( new FileReader(XSPUtil.relativeFilename(filename, request)), filename ), document ) From zvia@netmanage.co.il Mon Nov 22 14:21:57 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 20496 invoked from network); 22 Nov 1999 14:21:57 -0000 Received: from alpha.netvision.net.il (194.90.1.13) by apache.org with SMTP; 22 Nov 1999 14:21:57 -0000 Received: from netmanage.co.il (pc-zvi.netmanage.co.il [156.27.251.62]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id QAA22995; Mon, 22 Nov 1999 16:21:36 +0200 (IST) Message-ID: <3839515E.230095C6@netmanage.co.il> Date: Mon, 22 Nov 1999 16:21:18 +0200 From: Zvi Avraham Reply-To: zvia@netmanage.co.il Organization: NetManage X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Cocoon Multilingual Dictionary References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Ricardo, Is XSP already working ? Is it already in CVS ? Ricardo Rocha wrote: > Hello, > > It seems that "Cocoon Multilingual Dictionary" example doesn't’t work > > http://www.distributedsystems.com/cocoon/dcp/translator/ > Yes, there's a config problem at www.distributedsystems.com, sorry. > > The example is working fine for both DCP > (http://www.plenix.com/translator/) and XSP > (http://www.plenix.com/xsp/translator/). > > Sorry for the inconvenience. > > Ricardo -- ------------------------------------------------- Zvi Avraham, Server Team Leader NetManage Inc., Visual Connectivity Division http://www.netmanage.com/products/visual_conn.asp From ricardo@apache.org Mon Nov 22 15:33:24 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 28490 invoked from network); 22 Nov 1999 15:33:24 -0000 Received: from adsl-63-194-193-146.dsl.snfc21.pacbell.net (HELO ricardo.plenix.com) (root@63.194.193.146) by apache.org with SMTP; 22 Nov 1999 15:33:24 -0000 Received: from rrocha (rrocha.plenix.com [63.194.193.148]) by ricardo.plenix.com (8.9.3/8.8.7) with SMTP id IAA22045 for ; Mon, 22 Nov 1999 08:41:17 -0800 From: "Ricardo Rocha" To: Subject: RE: Cocoon Multilingual Dictionary Date: Mon, 22 Nov 1999 07:46:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3839515E.230095C6@netmanage.co.il> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Zvi Avraham wrote: > Is XSP already working ? There's an early (but working) implementation with some samples at http://www.plenix.com/xsp/ > Is it already in CVS ? Not yet, but hopefully soon Regards, Ricardo From gdaswani@esri.com Wed Nov 24 02:26:09 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 11848 invoked from network); 24 Nov 1999 02:26:09 -0000 Received: from wow.esri.com (HELO esri.com) (198.102.62.20) by taz.hyperreal.org with SMTP; 24 Nov 1999 02:26:09 -0000 Received: from esri.esri.com (esri [46.9.155.1]) by esri.com (8.8.8+Sun/8.8.8) with SMTP id SAA13967 for ; Tue, 23 Nov 1999 18:22:06 -0800 (PST) Received: from fugu by esri.esri.com (SMI-8.6/SMI-SVR4) id SAA04709; Tue, 23 Nov 1999 18:24:34 -0800 Message-ID: <004301bf3623$470b2050$fe28012e@esri.com> From: "George Henry C. Daswani" To: Subject: is there a way to do this? Date: Tue, 23 Nov 1999 18:25:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 I was wondering if there's a way to do this on cocoon.. Basically.. <------- test.xml ------> "> ]> &xmlSource; <------- test.xml ----> marketdata.handleDynamicCalls just returns an url with the proper get request.. eq.. test.xml?command=getAll will run and marketdata.handleDynamicCalls will return http://localhost/php/xmlProvider.php?command=getAll&cursorLocation=0&rowCoun t=10 and I want the output of that entered into &xmlSource; Is this possible? From jh@netland.inka.de Wed Nov 24 16:08:30 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 26780 invoked from network); 24 Nov 1999 16:08:30 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 24 Nov 1999 16:08:30 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11qey0-0001IZ-00; Wed, 24 Nov 1999 17:08:24 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id QAA85145 for ; Wed, 24 Nov 1999 16:23:16 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911241523.QAA85145@stiller.netland.inka.de> From: "Juergen Hermann" To: "Cocoon Developers" Date: Wed, 24 Nov 1999 16:21:07 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=_=_=IMA.BOUNDARY.FLPJZ6138764=_=_=_" Subject: Ant Builder Completed --_=_=_=IMA.BOUNDARY.FLPJZ6138764=_=_=_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! This is the completed builder, I changed a few things with regard to the original ECS way of things, especially the combination of core & options is automatic. You just have to set the env vars in the .bat correctly. If you CVS add these, please remove my path settings first (JSDK20, and the optional package paths). Ciao, Juergen --_=_=_=IMA.BOUNDARY.FLPJZ6138764=_=_=_ Content-Type: application/octet-stream; name="build-cocoon.bat" Content-Transfer-Encoding: base64 QGVjaG8gb2ZmCgpSRU0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpSRU0gRGVmaW5lIHRoZSBwYXRocyB0byBlYWNoIG9m IHRoZSBwYWNrYWdlcy4KUkVNIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUkVNICoqKiBKU0RLIDIuMApzZXQgSlNESzIw PUY6XEphdmFcSlNESzIuMFxsaWJcanNkay5qYXIKClJFTSAqKiogU3RhbmRhcmQgcGFja2FnZXMK c2V0IE9QRU5YTUw9Li5cYmluXG9wZW54bWwuMTA2LWZpeC5qYXIKc2V0IFhTTFA9Li5cYmluXHhz bHAuMTk5OTEwMTctZml4LmphcgpzZXQgRk9QPS4uXGJpblxmb3AuMDExMC5qYXIKClJFTSAqKiog T3B0aW9uYWwgcGFja2FnZXMgKHRvIG5vdCBpbmNsdWRlIHRoZW0sIHNldCB0byBub3RoaW5nKQpS RU0gc2V0IEZFU0k9ClJFTSBzZXQgU1VOWE1MPQpSRU0gc2V0IE9SQUNMRVhNTD0KUkVNIHNldCBJ Qk1YTUw9ClJFTSBzZXQgTE9UVVNYU0w9ClJFTSBzZXQgWFQ9CnNldCBGRVNJPUY6XEphdmFcZmVz aVxmZXNpLmphcgpzZXQgU1VOWE1MPUY6XEphdmFcUHJvamVjdC1YXHhtbC5qYXIKc2V0IE9SQUNM RVhNTD1GOlxKYXZhXE9yYWNsZVx4bWxwYXJzZXJfdjIuMC4yLjRcbGliXHhtbHBhcnNlcnYyLmph cgpzZXQgSUJNWE1MPUY6XEphdmFcQWxwaGFXb3Jrc1x4bWw0al8yXzBfMTVceG1sNGouamFyCnNl dCBMT1RVU1hTTD1GOlxKYXZhXEFscGhhV29ya3NcbG90dXN4c2xfMF8xOF81XGxvdHVzeHNsLmph cgpzZXQgWFQ9RjpcSmF2YVxKaW1DbGFya1x4dC5qYXIKClJFTSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClJFTSBXaGVy ZSBBbnQgaXMgbG9jYXRlZCAoaWYgaW4gdGhlIGN1cnJlbnQgZGlyZWN0b3J5LCBsZWF2ZSBlbXB0 eSkKUkVNIE5vdGUgdGhlIHRyYWlsaW5nIGJhY2tzbGFzaCEKUkVNIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kc2V0IEFO VD1GOlxKYXZhXEFudFwKClJFTSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpSRU0gTm8gbmVlZCB0byBlZGl0IGFueXRoaW5nIHBhc3QgaGVyZQpSRU0gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClJFTSAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpSRU0gVGhlIHRh cmdldHMgYXJlIHRoZSBkaWZmZXJlbnQgYnVpbGQgc2NyaXB0cy4KUkVNIApSRU0gImNvcmUiICAg ICAgICAgICB0YXJnZXQgYnVpbGRzIENvY29vbiBjb3JlIGNsYXNzZXMKUkVNICJlY21hc2NyaXB0 IiAgICAgdGFyZ2V0IGJ1aWxkcyBFQ01Bc2NyaXB0IHN1cHBvcnQgY2xhc3NlcwpSRU0gImlibXht bCIgICAgICAgICB0YXJnZXQgYnVpbGRzIHRoZSBJQk00SiBYTUwgUGFyc2VyClJFTSAibG90dXN4 c2wiICAgICAgIHRhcmdldCBidWlsZHMgdGhlIExvdHVzIFhTTFQgUHJvY2Vzc29yClJFTSAic3Vu eG1sIiAgICAgICAgIHRhcmdldCBidWlsZHMgdGhlIEphdmEgUHJvamVjdCBYIFBhcnNlcgpSRU0g Im9yYWNsZXhtbCIgICAgICB0YXJnZXQgYnVpbGRzIHRoZSBPcmFjbGUgWE1MIFBhcnNlciAmIFhT TFQgUHJvZHVjZXIKUkVNICJ4dCIgICAgICAgICAgICAgdGFyZ2V0IGJ1aWxkcyBKaW0gQ2xhcmsn cyBYVApSRU0gImNsZWFuIiAgICAgICAgICB0YXJnZXQgcmVtb3ZlcyB0ZW1wb3JhcnkgZGlyZWN0 b3JpZXMKUkVNICJkaXN0IiAgICAgICAgICAgdGFyZ2V0IGJ1aWxkcyAuLi9iaW4vQ29jb29uLmph cgpSRU0KUkVNIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCnNldCBUQVJHRVRTPWNvcmUKaWYgIiVGRVNJJSIgIT0gIiIgc2V0IFRBUkdF VFM9JVRBUkdFVFMlIGVjbWFzY3JpcHQKaWYgIiVTVU5YTUwlIiAhPSAiIiBzZXQgVEFSR0VUUz0l VEFSR0VUUyUgc3VueG1sCmlmICIlT1JBQ0xFWE1MJSIgIT0gIiIgc2V0IFRBUkdFVFM9JVRBUkdF VFMlIG9yYWNsZXhtbAppZiAiJUlCTVhNTCUiICE9ICIiIHNldCBUQVJHRVRTPSVUQVJHRVRTJSBp Ym14bWwKaWYgIiVMT1RVU1hTTCUiICE9ICIiIHNldCBUQVJHRVRTPSVUQVJHRVRTJSBsb3R1c3hz bAppZiAiJVhUJSIgIT0gIiIgc2V0IFRBUkdFVFM9JVRBUkdFVFMlIHh0CnNldCBUQVJHRVRTPSVU QVJHRVRTJSBkaXN0CgpJRiAiJTEiPSIiIEdPVE8gZGVmYXVsdF90YXJnZXQKc2V0IFRBUkdFVFM9 JTEKOmRlZmF1bHRfdGFyZ2V0CgpzZXQgQ1A9JUpTREsyMCU7JU9QRU5YTUwlOyVYU0xQJTslRk9Q JTslRkVTSSU7JVNVTlhNTCU7JU9SQUNMRVhNTCU7JUlCTVhNTCU7JUxPVFVTWFNMJTslWFQlOwpz ZXQgQ1A9JUNQJSVBTlQlYW50LmphcjslQU5UJXByb2plY3R4LXRyMi5qYXI7JUFOVCVqYXZhYy5q YXIKCnNldCBCVUlMREZJTEU9YnVpbGQtY29jb29uLnhtbAoKZWNobyBCdWlsZGluZyB0YXJnZXRz ICVUQVJHRVRTJSB3aXRoIGNsYXNzcGF0aCAlQ1AlLi4uCmVjaG8uCmphdmEgLWNsYXNzcGF0aCAl Q1AlIG9yZy5hcGFjaGUudG9vbHMuYW50Lk1haW4gLWJ1aWxkZmlsZSAlQlVJTERGSUxFJSAlVEFS R0VUUyUK --_=_=_=IMA.BOUNDARY.FLPJZ6138764=_=_=_ Content-Type: text/plain; name="build-cocoon.xml" Content-Transfer-Encoding: base64 PHByb2plY3QgbmFtZT0iWE1MLUNvY29vbiIgZGVmYXVsdD0iZGlzdCIgYmFzZWRpcj0iLiI+Cgog IDxwcm9wZXJ0eSBuYW1lPSJidWlsZC5jb21waWxlciIgdmFsdWU9ImNsYXNzaWMiLz4KICA8cHJv cGVydHkgbmFtZT0iYnVpbGQuZGlyIiB2YWx1ZT0iLi4vYmluIi8+CiAgPHByb3BlcnR5IG5hbWU9 ImJ1aWxkLnNyYyIgdmFsdWU9Ii4vc3JjIi8+CiAgPHByb3BlcnR5IG5hbWU9ImJ1aWxkLmRlc3Qi IHZhbHVlPSIuL2NsYXNzZXMiLz4KICA8cHJvcGVydHkgbmFtZT0ic3JjLmphdmEuZGlyIiB2YWx1 ZT0iLi4vc3JjIi8+CiAgPHByb3BlcnR5IG5hbWU9ImRlYnVnIiB2YWx1ZT0ib2ZmIi8+CgogIDx0 YXJnZXQgbmFtZT0ic3VueG1sIj4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9v cmcvYXBhY2hlL2NvY29vbi9wYXJzZXIvU3VuWE1MUGFyc2VyLmphdmEiIGRlc3Q9IiR7YnVpbGQu c3JjfS9vcmcvYXBhY2hlL2NvY29vbi9wYXJzZXIvU3VuWE1MUGFyc2VyLmphdmEiLz4KICA8L3Rh cmdldD4KCiAgPHRhcmdldCBuYW1lPSJvcmFjbGV4bWwiPgogICAgPGNvcHlmaWxlIHNyYz0iJHtz cmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9PcmFjbGVYTUxQYXJzZXIuamF2 YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9PcmFjbGVYTUxQ YXJzZXIuamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFj aGUvY29jb29uL3Byb2Nlc3Nvci94c2x0L09yYWNsZVhTTFByb2Nlc3Nvci5qYXZhIiBkZXN0PSIk e2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vcHJvY2Vzc29yL3hzbHQvT3JhY2xlWFNMUHJv Y2Vzc29yLmphdmEiLz4KICA8L3RhcmdldD4KCiAgPHRhcmdldCBuYW1lPSJpYm14bWwiPgogICAg PGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9J Qk1YTUxQYXJzZXIuamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3Bh cnNlci9JQk1YTUxQYXJzZXIuamF2YSIvPgogIDwvdGFyZ2V0PgoKICA8dGFyZ2V0IG5hbWU9Imxv dHVzeHNsIj4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2Nv Y29vbi9wcm9jZXNzb3IveHNsdC9Mb3R1c1hTTFByb2Nlc3Nvci5qYXZhIiBkZXN0PSIke2J1aWxk LnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vcHJvY2Vzc29yL3hzbHQvTG90dXNYU0xQcm9jZXNzb3Iu amF2YSIvPgogIDwvdGFyZ2V0PgoKICA8dGFyZ2V0IG5hbWU9Inh0Ij4KICAgIDxjb3B5ZmlsZSBz cmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9jZXNzb3IveHNsdC9YVFBy b2Nlc3Nvci5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vcHJvY2Vz c29yL3hzbHQvWFRQcm9jZXNzb3IuamF2YSIvPgogIDwvdGFyZ2V0PgoKICA8dGFyZ2V0IG5hbWU9 ImVjbWFzY3JpcHQiPgogICAgPG1rZGlyIGRpcj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29j b29uL2ludGVycHJldGVyL2VjbWFzY3JpcHQiLz4KICAgIDxjb3B5ZGlyIHNyYz0iJHtzcmMuamF2 YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL2ludGVycHJldGVyL2VjbWFzY3JpcHQiIGRlc3Q9IiR7 YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9pbnRlcnByZXRlci9lY21hc2NyaXB0Ii8+CiAg ICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJw cmV0ZXIvZWNtYXNjcmlwdC9pbml0U2NyaXB0LmVzIiBkZXN0PSIke2J1aWxkLmRlc3R9L29yZy9h cGFjaGUvY29jb29uL2ludGVycHJldGVyL2VjbWFzY3JpcHQvaW5pdFNjcmlwdC5lcyIvPgogIDwv dGFyZ2V0PgoKICA8dGFyZ2V0IG5hbWU9ImNvcmUiPgogICAgPCEtLSBjcmVhdGUgdGVtcG9yYXJ5 IGJ1aWxkIGRpcnMgLS0+CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLmRpcn0iLz4KICAgIDxta2Rp ciBkaXI9IiR7YnVpbGQuc3JjfSIvPgogICAgPG1rZGlyIGRpcj0iJHtidWlsZC5kZXN0fSIvPgoK ICAgIDwhLS0gY3JlYXRlIHNoYWRvdyBzcmMgdHJlZSAtLT4KICAgIDxta2RpciBkaXI9IiR7YnVp bGQuc3JjfS9vcmciLz4KICAgIDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlIi8+ CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24iLz4KICAgIDxt a2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9jYWNoZSIvPgogICAgPG1r ZGlyIGRpcj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2NvbXBpbGVyIi8+CiAgICA8 bWtkaXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vZGNwIi8+CiAgICA8bWtk aXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vZXhhbXBsZSIvPgogICAgPG1r ZGlyIGRpcj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlciIvPgogICAg PG1rZGlyIGRpcj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci9odG1s Ii8+CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0 dGVyL2ltYWdlIi8+CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nv b24vZm9ybWF0dGVyL2phdmEiLz4KICAgIDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBh Y2hlL2NvY29vbi9mb3JtYXR0ZXIvcGRmIi8+CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLnNyY30v b3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL3dtbCIvPgogICAgPG1rZGlyIGRpcj0iJHtidWls ZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci94aHRtbCIvPgogICAgPG1rZGlyIGRp cj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci94bWwiLz4KICAgIDxt a2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9mcmFtZXdvcmsiLz4KICAg IDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9pbnRlcnByZXRlciIv PgogICAgPG1rZGlyIGRpcj0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2ludGVycHJl dGVyL2phdmEiLz4KICAgIDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29v bi9wYXJzZXIiLz4KICAgIDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29v bi9wcm9jZXNzb3IiLz4KICAgIDxta2RpciBkaXI9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2Nv Y29vbi9wcm9jZXNzb3IvZGNwIi8+CiAgICA8bWtkaXIgZGlyPSIke2J1aWxkLnNyY30vb3JnL2Fw YWNoZS9jb2Nvb24vcHJvY2Vzc29yL3NxbCIvPgogICAgPG1rZGlyIGRpcj0iJHtidWlsZC5zcmN9 L29yZy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nvci94c2x0Ii8+CiAgICA8bWtkaXIgZGlyPSIke2J1 aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vcHJvZHVjZXIiLz4KICAgIDxta2RpciBkaXI9IiR7 YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9zdG9yZSIvPgoKICAgIDwhLS0gY29weSBjb3Jl IGRpcnMgLS0+CiAgICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2Nv Y29vbi9jYWNoZSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2NhY2hlIi8+ CiAgICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9jb21w aWxlciIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2NvbXBpbGVyIi8+CiAg ICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9kY3AiIGRl c3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9kY3AiLz4KICAgIDxjb3B5ZGlyIHNy Yz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL2V4YW1wbGUiIGRlc3Q9IiR7YnVp bGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9leGFtcGxlIi8+CiAgICA8Y29weWRpciBzcmM9IiR7 c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9mb3JtYXR0ZXIvaHRtbCIgZGVzdD0iJHti dWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci9odG1sIi8+CiAgICA8IS0tIGNv cHlkaXIgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL2lt YWdlIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL2ltYWdl Ii8gLS0+CiAgICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29v bi9mb3JtYXR0ZXIvamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zv cm1hdHRlci9qYXZhIi8+CiAgICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBh Y2hlL2NvY29vbi9mb3JtYXR0ZXIvcGRmIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9j b2Nvb24vZm9ybWF0dGVyL3BkZiIvPgogICAgPGNvcHlkaXIgc3JjPSIke3NyYy5qYXZhLmRpcn0v b3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL3dtbCIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9h cGFjaGUvY29jb29uL2Zvcm1hdHRlci93bWwiLz4KICAgIDxjb3B5ZGlyIHNyYz0iJHtzcmMuamF2 YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci94aHRtbCIgZGVzdD0iJHtidWlsZC5z cmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci94aHRtbCIvPgogICAgPGNvcHlkaXIgc3Jj PSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL3htbCIgZGVzdD0i JHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci94bWwiLz4KICAgIDxjb3B5 ZGlyIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL2ZyYW1ld29yayIgZGVz dD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2ZyYW1ld29yayIvPgogICAgPGNvcHlk aXIgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvamF2 YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL2ludGVycHJldGVyL2phdmEi Lz4KICAgIDxjb3B5ZGlyIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3By b2Nlc3Nvci9kY3AiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9jZXNz b3IvZGNwIi8+CiAgICA8Y29weWRpciBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2Nv Y29vbi9wcm9jZXNzb3Ivc3FsIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24v cHJvY2Vzc29yL3NxbCIvPgogICAgPCEtLSBjb3B5ZGlyIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29y Zy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nvci94c2x0IiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2Fw YWNoZS9jb2Nvb24vcHJvY2Vzc29yL3hzbHQiLyAtLT4KICAgIDxjb3B5ZGlyIHNyYz0iJHtzcmMu amF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3Byb2R1Y2VyIiBkZXN0PSIke2J1aWxkLnNyY30v b3JnL2FwYWNoZS9jb2Nvb24vcHJvZHVjZXIiLz4KICAgIDxjb3B5ZGlyIHNyYz0iJHtzcmMuamF2 YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3N0b3JlIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2Fw YWNoZS9jb2Nvb24vc3RvcmUiLz4KCiAgICA8IS0tIHBhcnNlciBjb3JlIC0tPgogICAgPGNvcHlm aWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9QYXJzZXIu amF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9QYXJzZXIu amF2YSIvPgogICAgICAgIAogICAgPCEtLSBmb3JtYXR0ZXIgY29yZSAtLT4KICAgIDxjb3B5Zmls ZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9mb3JtYXR0ZXIvRm9ybWF0 dGVyLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9mb3JtYXR0ZXIv Rm9ybWF0dGVyLmphdmEiLz4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcv YXBhY2hlL2NvY29vbi9mb3JtYXR0ZXIvRm9ybWF0dGVyRmFjdG9yeS5qYXZhIiBkZXN0PSIke2J1 aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vZm9ybWF0dGVyL0Zvcm1hdHRlckZhY3RvcnkuamF2 YSIvPgoKICAgIDwhLS0gcHJvY2Vzc29yIGNvcmUgLS0+CiAgICA8Y29weWZpbGUgc3JjPSIke3Ny Yy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vcHJvY2Vzc29yL1BJTm90Rm91bmRFeGNlcHRp b24uamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nvci9Q SU5vdEZvdW5kRXhjZXB0aW9uLmphdmEiLz4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEu ZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9jZXNzb3IvUHJvY2Vzc29yLmphdmEiIGRlc3Q9IiR7 YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9jZXNzb3IvUHJvY2Vzc29yLmphdmEiLz4K ICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9j ZXNzb3IvUHJvY2Vzc29yRXhjZXB0aW9uLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBh Y2hlL2NvY29vbi9wcm9jZXNzb3IvUHJvY2Vzc29yRXhjZXB0aW9uLmphdmEiLz4KICAgIDxjb3B5 ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9wcm9jZXNzb3IvUHJv Y2Vzc29yRmFjdG9yeS5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24v cHJvY2Vzc29yL1Byb2Nlc3NvckZhY3RvcnkuamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtz cmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nvci94c2x0L0Fic3RyYWN0WFNM VFByb2Nlc3Nvci5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vcHJv Y2Vzc29yL3hzbHQvQWJzdHJhY3RYU0xUUHJvY2Vzc29yLmphdmEiLz4KCiAgICA8IS0tIGludGVy cHJldGVyIGNvcmUgLS0+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2Fw YWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvQWJzdHJhY3RJbnRlcnByZXRlci5qYXZhIiBkZXN0PSIk e2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvQWJzdHJhY3RJbnRlcnBy ZXRlci5qYXZhIi8+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNo ZS9jb2Nvb24vaW50ZXJwcmV0ZXIvSW5zdGFuY2UuamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29y Zy9hcGFjaGUvY29jb29uL2ludGVycHJldGVyL0luc3RhbmNlLmphdmEiLz4KICAgIDxjb3B5Zmls ZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9pbnRlcnByZXRlci9JbnRl cnByZXRlci5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJw cmV0ZXIvSW50ZXJwcmV0ZXIuamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5k aXJ9L29yZy9hcGFjaGUvY29jb29uL2ludGVycHJldGVyL0ludGVycHJldGVyRmFjdG9yeS5qYXZh IiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvSW50ZXJw cmV0ZXJGYWN0b3J5LmphdmEiLz4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9v cmcvYXBhY2hlL2NvY29vbi9pbnRlcnByZXRlci9MYW5ndWFnZUV4Y2VwdGlvbi5qYXZhIiBkZXN0 PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvTGFuZ3VhZ2VFeGNl cHRpb24uamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFj aGUvY29jb29uL2ludGVycHJldGVyL01vZHVsZS5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3Jn L2FwYWNoZS9jb2Nvb24vaW50ZXJwcmV0ZXIvTW9kdWxlLmphdmEiLz4KCiAgICA8IS0tIENvY29v biBjb3JlIC0tPgogICAgPGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUv Y29jb29uL0Jyb3dzZXJzLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29v bi9Ccm93c2Vycy5qYXZhIi8+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3Jn L2FwYWNoZS9jb2Nvb24vQ29jb29uLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hl L2NvY29vbi9Db2Nvb24uamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9 L29yZy9hcGFjaGUvY29jb29uL0RlZmF1bHRzLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcv YXBhY2hlL2NvY29vbi9EZWZhdWx0cy5qYXZhIi8+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5q YXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24vRW5naW5lLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3Jj fS9vcmcvYXBhY2hlL2NvY29vbi9FbmdpbmUuamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0iJHtz cmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL0VuZ2luZVdyYXBwZXIuamF2YSIgZGVzdD0i JHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL0VuZ2luZVdyYXBwZXIuamF2YSIvPgogICAg PGNvcHlmaWxlIHNyYz0iJHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL0Zyb250ZW5k LmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9Gcm9udGVuZC5qYXZh Ii8+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRpcn0vb3JnL2FwYWNoZS9jb2Nvb24v VXRpbHMuamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL1V0aWxzLmph dmEiLz4KCiAgICA8IS0tIE9wZW5YTUwgYW5kIFhTTDpQIC0tPgogICAgPGNvcHlmaWxlIHNyYz0i JHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL2Zvcm1hdHRlci9PcGVuWE1MRm9ybWF0 dGVyLmphdmEiIGRlc3Q9IiR7YnVpbGQuc3JjfS9vcmcvYXBhY2hlL2NvY29vbi9mb3JtYXR0ZXIv T3BlblhNTEZvcm1hdHRlci5qYXZhIi8+CiAgICA8Y29weWZpbGUgc3JjPSIke3NyYy5qYXZhLmRp cn0vb3JnL2FwYWNoZS9jb2Nvb24vcGFyc2VyL09wZW5YTUxQYXJzZXIuamF2YSIgZGVzdD0iJHti dWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3BhcnNlci9PcGVuWE1MUGFyc2VyLmphdmEiLz4K ICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEuZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9mb3Jt YXR0ZXIvWFNMUEZvcm1hdHRlci5qYXZhIiBkZXN0PSIke2J1aWxkLnNyY30vb3JnL2FwYWNoZS9j b2Nvb24vZm9ybWF0dGVyL1hTTFBGb3JtYXR0ZXIuamF2YSIvPgogICAgPGNvcHlmaWxlIHNyYz0i JHtzcmMuamF2YS5kaXJ9L29yZy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nvci94c2x0L1hTTFBQcm9j ZXNzb3IuamF2YSIgZGVzdD0iJHtidWlsZC5zcmN9L29yZy9hcGFjaGUvY29jb29uL3Byb2Nlc3Nv ci94c2x0L1hTTFBQcm9jZXNzb3IuamF2YSIvPgogIDwvdGFyZ2V0PgoKICA8dGFyZ2V0IG5hbWU9 ImNvbXBpbGUiPgogICAgPGphdmFjIHNyY2Rpcj0iJHtidWlsZC5zcmN9IiBkZXN0ZGlyPSIke2J1 aWxkLmRlc3R9IiBkZWJ1Zz0iJHtkZWJ1Z30iLz4KICA8L3RhcmdldD4KCiAgPHRhcmdldCBuYW1l PSJkaXN0IiBkZXBlbmRzPSJjb21waWxlIj4KICAgIDxjb3B5ZmlsZSBzcmM9IiR7c3JjLmphdmEu ZGlyfS9vcmcvYXBhY2hlL2NvY29vbi9jb2Nvb24ucHJvcGVydGllcyIgZGVzdD0iJHtidWlsZC5k ZXN0fS9vcmcvYXBhY2hlL2NvY29vbi9jb2Nvb24ucHJvcGVydGllcyIvPgogICAgPGNvcHlmaWxl IHNyYz0iJHtzcmMuamF2YS5kaXJ9L01BTklGRVNUIiBkZXN0PSIke2J1aWxkLmRlc3R9L01BTklG RVNUIi8+CiAgICA8amFyIGphcmZpbGU9IiR7YnVpbGQuZGlyfS9Db2Nvb24uamFyIiBiYXNlZGly PSIke2J1aWxkLmRlc3R9IiBpdGVtcz0iTUFOSUZFU1Qsb3JnIi8+CiAgPC90YXJnZXQ+CgogIDx0 YXJnZXQgbmFtZT0iY2xlYW4iPgogICAgPGRlbHRyZWUgZGlyPSIke2J1aWxkLnNyY30iLz4KICAg IDxkZWx0cmVlIGRpcj0iJHtidWlsZC5kZXN0fSIvPgogIDwvdGFyZ2V0PgoKPC9wcm9qZWN0Pgo= --_=_=_=IMA.BOUNDARY.FLPJZ6138764=_=_=_-- From stefano@apache.org Wed Nov 24 18:39:38 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 14248 invoked from network); 24 Nov 1999 18:39:38 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 24 Nov 1999 18:39:38 -0000 Received: from apache.org (pv1-pri.systemy.it [194.21.255.1]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id TAA16614; Wed, 24 Nov 1999 19:39:24 +0100 Message-ID: <383BB682.777AC94A@apache.org> Date: Wed, 24 Nov 1999 10:57:22 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: Cocoon CC: Cocoon Subject: Cocoon on its new home! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [crossposting since I know you guys/girls are lazy and you didn't get out of here yet! Move!] Donald Ball wrote: > > i'm very confused about where and what is going on with the active > development of cocoon. i can't log in with any username/password to the > cvs server at dev.apache.org. The module that i did check out anonymously > is still using DOM stuff and there's no hint of XSP anywhere, while I > thought that the version of cocoon living on xml.apache.org had moved to > SAX, didn't work yet, and had some XSP support already. I'm super > confused... > > Boy, this move to xml.apache.org, while it might be a grand thing in the > long run, is sure mucking up development right now. Can't we just copy > over everything intact from java.apache.org? Change is bad, we fear > change.... :) My fault. I should have planned this more carefully. 1) 1.6-dev was moved from java.apache to xml.apache with very little changes on the architectural code. Still DOM support, no XSP support (but I have an XSPProcessor fully working right now written by Ricardo, it's just not in the CVS since he's stuck like you :) the changes done up to today are a) xml parsers supported: - Apache Xerces 1.0.0 [default] - Sun ProjectX TR2 - OpenXML 1.1 (currently broken due to a bug to be fixed soon) - Oracle XML Parser v2.0.0 Note: both ProjectX and OpenXML will be merged with Xerces so their direct support will be deprecated in the future. b) xslt processors supported: - Apache Xalan 0.19.0 [default] - JClark XT - KVisco XSL:P 1.0 beta Note: XSL:P will be merged with Xalan so its direct support will be deprecated in the future. c) other stuff used - Apache FOP 0.12.0 - Apache Xerces Serializers (donated by Assaf Arkin to Xerces from OpenXML/XSL:P) [not yet available] d) documentation moved to XML - creation of the "Apache Documentation DTD 1.0a" (still in working draft) using "XML Specification DTD v2.0" by Eve Maler (elm@arbortext.com) used by W3C to edit their own specifications, plus using HTML 4.0 as a reference base for tags. Feedback welcome. - porting of HTML -> XML for all HTML documentation - porting to XML of both changes.xml and todo.xml e) building system uses Jakarta Ant - the makefiles were removed - a build.xml file for Ant has been created (with notes inside on stuff yet to be written to make Ant a total replacement of gmake on this project) f) following the general xml.apache.org naming conventions, the Cocoon design pattern "formatter" was turned into "serializer". 2) planned stuff for this week: - import a "cocoon-2" CVS branch with the interfaces for Cocoon 2 so that discussion can take place on the new architecture with code to look at. (nothing working, just architectural frameworks) - import Ricardo's XSPProcessor (Ricardo? are you clear for that?) - write the new serializers using Arkin's donation - create a sitemap design document and an initial DTD using Stylebook project.dtd as an example - writing the changes.dtd, faq.dtd, todo.dtd and spec.dtd to complete the validation of the documentation. - have Donald move his "SQLProcessor User Guide" to XML using the "Documentation DTD" - have Ricardo move his "DCPProcessor User Guide" to XML using the "Documentation DTD" 3) planned stuff for next weeks - work with Pier on the integration with Stylebook (Pier, what's the status of StyleBook?) - write the new tasks for Ant to make it fully working for us (add XSLT support and bunch of other small things, see build.xml for details) Ok, this is what you find there. We plan to remove the CVS Cocoon module from java.apache this weekend and to shut down this mail list next week, after the cocoon-user@xml.apache.org mail list has been set up (Brian will do that over the week-end). Hope this helps. :) -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From stefano@apache.org Wed Nov 24 18:40:02 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 15211 invoked from network); 24 Nov 1999 18:40:02 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 24 Nov 1999 18:40:02 -0000 Received: from apache.org (pv1-pri.systemy.it [194.21.255.1]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id TAA16709 for ; Wed, 24 Nov 1999 19:39:58 +0100 Message-ID: <383BCCAD.97F1B468@apache.org> Date: Wed, 24 Nov 1999 12:31:57 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: is there a way to do this? References: <004301bf3623$470b2050$fe28012e@esri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "George Henry C. Daswani" wrote: > > I was wondering if there's a way to do this on cocoon.. > > Basically.. > > <------- test.xml ------> > > > > method="marketdata.handleDynamicCalls"?>"> > ]> > > > > &xmlSource; > > <------- test.xml ----> > > marketdata.handleDynamicCalls just returns > an url with the proper get request.. > > eq.. > > test.xml?command=getAll > > will run and marketdata.handleDynamicCalls will return > > http://localhost/php/xmlProvider.php?command=getAll&cursorLocation=0&rowCoun > t=10 > > and I want the output of that entered into > > > &xmlSource; > > > Is this possible? Not really clean, but yes, it's possible. Do a DCP method that fetches the requested URL (directly via HTTP) and copies it there. Not clean since you have to go back out to the front of the web server and back again. Apache 2.0 will give us more hooks to do that internally. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From pphalen@teleo.net Wed Nov 24 19:25:09 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 17090 invoked from network); 24 Nov 1999 19:25:09 -0000 Received: from hydra.teleo.net (HELO mx.teleo.net) (209.0.53.66) by taz.hyperreal.org with SMTP; 24 Nov 1999 19:25:09 -0000 Received: (qmail 8847 invoked from network); 24 Nov 1999 19:17:51 -0000 Received: from unknown (HELO quadra.teleo.net) (192.168.1.2) by 192.168.1.7 with SMTP; 24 Nov 1999 19:17:51 -0000 From: Patrick Phalen Organization: TeleoNet To: cocoon@list.working-dogs.com Subject: Re: Cocoon on its new home! Date: Wed, 24 Nov 1999 11:17:53 -0800 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: cocoon-dev@xml.apache.org References: <383BB682.777AC94A@apache.org> In-Reply-To: <383BB682.777AC94A@apache.org> MIME-Version: 1.0 Message-Id: <99112411260902.01129@quadra.teleo.net> Content-Transfer-Encoding: 8bit [Stefano Mazzocchi, on Wed, 24 Nov 1999] :: [crossposting since I know you guys/girls are lazy and you didn't get :: out of here yet! Move!] Unless I missed a post, I don't think the actual procedure has been clarified. I'm currently subscribed to both lists (got both of your messages, Stefano). Is it premature to unsubscribe from working-dogs? Don't want to miss anything. Will unsubscribing be unnecessary (IOW, will you simply kill the w-d list server eventually)? From Jens.Gohrke@jSoft.de Wed Nov 24 20:36:06 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 21510 invoked from network); 24 Nov 1999 20:36:06 -0000 Received: from elch.de.uu.net (192.76.144.55) by taz.hyperreal.org with SMTP; 24 Nov 1999 20:36:06 -0000 Received: from merlin.jsoft.de (pec-45-153.tnt3.s2.uunet.de [149.225.45.153]) by elch.de.uu.net (5.5.5/5.5.5) with ESMTP id VAA05726 for ; Wed, 24 Nov 1999 21:33:36 +0100 (MET) Received: from janus.fast.jsoft.de (janus.fast.jsoft.de [192.168.0.1]) by merlin.jsoft.de (8.9.3/8.8.7) with SMTP id VAA10082 for ; Wed, 24 Nov 1999 21:21:18 +0100 From: Jens Gohrke Organization: jSoft Softwareentwicklungs GmbH To: Subject: Re: Problems with html output, DCP and , URL parameters Date: Wed, 24 Nov 1999 21:04:50 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <99112421215704.00826@janus.fast.jsoft.de> Content-Transfer-Encoding: 8bit > > If I got this one wrong - please yell at me ... it would safe quite some > > time. > Uh, yeah, I think you did get this one wrong. If you have the following > PIs in your initial XML document: > > > > > > The DCP processor will be invoked first and the PIs will > be expanded. The the XSLT processor will be invoked and the XML tree will > be transformed using the XSL stylesheet into an XML results tree, which > will then be rendered using HTML rules. > > Note that you could just have these in your initial document: > > > > > and if your DCP method creates a PI named "cocoon-process" with a > type="xslt" attribute, the XSLT processor will still be invoked. That was probably my mistake at that time... looked at my old tests and found that i somehow dropped that PI in the DCP method. Thanks for clarifying that one, Donald. Nevertheless, if I do need some more control like in my case (there is some quite asynchronous action while creation of the actual content which is done on maybe another host) i might want to handle exceptions and alike ... I will be forced into writing a Producer rather than a DCP method, i am probably right there ?!? :) Sorry guys, if I misled You there... but this way we all learned a little :) Cheers Jens From balld@phoenix.webslingerZ.com Wed Nov 24 20:44:04 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 1594 invoked from network); 24 Nov 1999 20:44:04 -0000 Received: from phoenix.webslingerz.com (balld@206.66.49.24) by taz.hyperreal.org with SMTP; 24 Nov 1999 20:44:04 -0000 Received: from localhost (balld@localhost) by phoenix.webslingerZ.com (8.8.7/8.8.7) with ESMTP id PAA12640 for ; Wed, 24 Nov 1999 15:45:48 -0500 Date: Wed, 24 Nov 1999 15:45:48 -0500 (EST) From: Donald Ball To: cocoon-dev@xml.apache.org Subject: Re: Problems with html output, DCP and , URL parameters In-Reply-To: <99112421215704.00826@janus.fast.jsoft.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 24 Nov 1999, Jens Gohrke wrote: > > > > If I got this one wrong - please yell at me ... it would safe quite some > > > time. > > Uh, yeah, I think you did get this one wrong. If you have the following > > PIs in your initial XML document: > > > > > > > > > > > > The DCP processor will be invoked first and the PIs will > > be expanded. The the XSLT processor will be invoked and the XML tree will > > be transformed using the XSL stylesheet into an XML results tree, which > > will then be rendered using HTML rules. > > > > Note that you could just have these in your initial document: > > > > > > > > > > and if your DCP method creates a PI named "cocoon-process" with a > > type="xslt" attribute, the XSLT processor will still be invoked. > > That was probably my mistake at that time... looked at my old tests > and found that i somehow dropped that PI in the DCP method. Thanks for > clarifying that one, Donald. > > Nevertheless, if I do need some more control like in my case (there > is some quite asynchronous action while creation of the actual content > which is done on maybe another host) i might want to handle exceptions > and alike ... I will be forced into writing a Producer rather than > a DCP method, i am probably right there ?!? :) Probably you want to write a Processor rather than a Producer to replace your DCP method. My tired refrain goes: 1. You can only have one Producer involved in a request, but can have multiple Processors. If I'd written SQLProcessor as a Producer and you wrote your special XML generator as a Producer and then you wanted to use them both in the same page, you'd be SOL, no way you could do it. 2. Processors are configured through XML fragments _and_ request parameters. Producers only get request parameters and it's often a pain to squeeze all of your configuration stuff into a URL (e.g. dburl, driver, etc.) - donald From Jens.Gohrke@jSoft.de Wed Nov 24 23:20:53 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 14651 invoked from network); 24 Nov 1999 23:20:53 -0000 Received: from elch.de.uu.net (192.76.144.55) by taz.hyperreal.org with SMTP; 24 Nov 1999 23:20:53 -0000 Received: from merlin.jsoft.de (pec-0-155.tnt1.s2.uunet.de [149.225.0.155]) by elch.de.uu.net (5.5.5/5.5.5) with ESMTP id AAA01453 for ; Thu, 25 Nov 1999 00:18:28 +0100 (MET) Received: from janus.fast.jsoft.de (janus.fast.jsoft.de [192.168.0.1]) by merlin.jsoft.de (8.9.3/8.8.7) with SMTP id AAA11793 for ; Thu, 25 Nov 1999 00:19:09 +0100 From: Jens Gohrke Organization: jSoft Softwareentwicklungs GmbH To: cocoon-dev@xml.apache.org Subject: Re: Problems with html output, DCP and , URL parameters Date: Wed, 24 Nov 1999 23:58:35 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: In-Reply-To: MIME-Version: 1.0 Message-Id: <99112500194805.00826@janus.fast.jsoft.de> Content-Transfer-Encoding: 8bit > Probably you want to write a Processor rather than a Producer to replace > your DCP method. My tired refrain goes: > > 1. You can only have one Producer involved in a request, but can have > multiple Processors. If I'd written SQLProcessor as a Producer and > you wrote your special XML generator as a Producer and then you wanted to > use them both in the same page, you'd be SOL, no way you could do it. > > 2. Processors are configured through XML fragments _and_ request > parameters. Producers only get request parameters and it's often a pain > to squeeze all of your configuration stuff into a URL (e.g. dburl, > driver, etc.) Thanks again - didn't think about it that way round... extra flexibility. Didn't need it so far but looks like demand is in sight at the horizon. A clear ++ again. Although the URL might not be too crowded if we talk about a POST... but maybe that's not really a good practice anyway ;) But surely You get extra flexibility and "combinability" for the site-admin at no cost, without recoding. But I'll leave it to that now and have a shot at implementing a Processor for trial - maybe I'll like that more... :) Cheers Jens PS: I'm not really sure whether the first part of the original question of this thread got really clarified already?? From jh@netland.inka.de Thu Nov 25 02:12:41 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 11670 invoked from network); 25 Nov 1999 02:12:41 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 25 Nov 1999 02:12:41 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11qoOh-0007A2-00; Thu, 25 Nov 1999 03:12:35 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id TAA90921 for ; Wed, 24 Nov 1999 19:19:25 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911241819.TAA90921@stiller.netland.inka.de> From: "Juergen Hermann" To: "Cocoon Developers" Date: Wed, 24 Nov 1999 19:17:03 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Ant building how-to This didn't make it fully to the old list, so I repost it here w/o the old attachments... Hi! Included you find a .bat and .xml to build Cocoon using Ant. Follow these steps: 1. go to your Cocoon root dir. 2. make a "build" directory. 3. copy the attached files into it. 4. copy the Ant support files from the ECS "build" directory. [NOTE: in the new version, you can simply set the ANT var to a directory containing these files] You should get this: 36810 Nov 24 10:44 ant.jar 1544 Nov 24 13:48 build-cocoon.bat 10467 Nov 24 13:13 build-cocoon.xml 2020049 Nov 23 03:55 javac.jar 132472 Nov 23 03:55 projectx-tr2.jar 5. change "build-cocoon.bat" to match your configuration, especially change the JSDK20 and FESI variables. 6. call "build-cocoon" and rejoice! What's missing is support for the IBM, Oracle and Lotus options. I'll add that soon. [NOTE: added now] "build-cocoon clean" will remove all generated files EXCEPT "bin/Cocoon.jar". Ciao, Juergen From jh@netland.inka.de Thu Nov 25 10:07:41 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 19020 invoked from network); 25 Nov 1999 10:07:41 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 25 Nov 1999 10:07:41 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11qvoQ-0001tq-00; Thu, 25 Nov 1999 11:07:38 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id KAA17055 for ; Thu, 25 Nov 1999 10:26:29 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911250926.KAA17055@stiller.netland.inka.de> From: "Juergen Hermann" To: "cocoon-dev@xml.apache.org" Date: Thu, 25 Nov 1999 10:23:41 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Cocoon on its new home! On Wed, 24 Nov 1999 10:57:22 +0100, Stefano Mazzocchi wrote: >d) documentation moved to XML > > - creation of the "Apache Documentation DTD 1.0a" (still in working >draft) using "XML Specification DTD v2.0" by Eve Maler >(elm@arbortext.com) used by W3C to edit their own specifications, plus >using HTML 4.0 as a reference base for tags. Feedback welcome. > > - porting of HTML -> XML for all HTML documentation > - porting to XML of both changes.xml and todo.xml Did you consider DocBook? Just FYI, it has the advantage that it's stable and being actively worked on as its own project (you know, duplication of efforts and all). Ciao, Juergen From jh@netland.inka.de Thu Nov 25 14:07:37 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 19716 invoked from network); 25 Nov 1999 14:07:37 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 25 Nov 1999 14:07:37 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11qzYc-0001qK-00; Thu, 25 Nov 1999 15:07:34 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id NAA22441 for ; Thu, 25 Nov 1999 13:48:46 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911251248.NAA22441@stiller.netland.inka.de> From: "Juergen Hermann" To: "Cocoon Developers" Date: Thu, 25 Nov 1999 13:45:52 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=_=_=IMA.BOUNDARY.FLR7GG138764=_=_=_" Subject: XML Icon --_=_=_=IMA.BOUNDARY.FLR7GG138764=_=_=_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Attached is an icon that can be used as follows with Apache: AddIcon /icons/xml.gif .xml .xsl --_=_=_=IMA.BOUNDARY.FLR7GG138764=_=_=_ Content-Type: image/gif; name="xml.gif" Content-Transfer-Encoding: base64 R0lGODlhFAAWAPf/AAAAADMzM5mZmcz//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAUABYA AAieAAMIHEhw4ICDCAcEIMCwocOFARIeXMgQAACHBChGTEgRAMWHDTdOJOARI8OPGRF2RFkxgMeX IytedGixpsWYJh0K2CkAwMiLQAUQ6Ely6E6fCjMKWGixJ9CGPWPOfPqUYdSkAZYWrbh1KFKmRWeG tegVZ06MV1liJGv169mQM9O+hVs26VyXbc2aZFtX7du0WXkKHrwU6UGbiBMjDQgAOw== --_=_=_=IMA.BOUNDARY.FLR7GG138764=_=_=_-- From jh@netland.inka.de Thu Nov 25 14:07:38 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 19727 invoked from network); 25 Nov 1999 14:07:38 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 25 Nov 1999 14:07:38 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11qzYd-0001qS-00; Thu, 25 Nov 1999 15:07:35 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id OAA23700 for ; Thu, 25 Nov 1999 14:33:53 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911251333.OAA23700@stiller.netland.inka.de> From: "Juergen Hermann" To: "Cocoon Developers" Date: Thu, 25 Nov 1999 14:30:58 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=_=_=IMA.BOUNDARY.FLR9JM138764=_=_=_" Subject: page.xsl --_=_=_=IMA.BOUNDARY.FLR9JM138764=_=_=_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! This is (the start of) an XSLT sheet for the doc pages. Note that I created it by reading the .xml files and not the page.dtd, so it's neither complete nor necessarily correct. Ciao, Juergen --_=_=_=IMA.BOUNDARY.FLR9JM138764=_=_=_ Content-Type: text/plain; name="page.xsl" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8IURPQ1RZUEUgeHNs OnN0eWxlc2hlZXQgWwo8IUVOVElUWSBjb3B5ICAgIiYjMTY5OyI+CjwhRU5USVRZIG5ic3AgICAi JiMxNjA7Ij4KXT4KPHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIKICAgICAgICAgICAgICAg IHhtbG5zOnhzbD0iaHR0cDovL3d3dy53My5vcmcvMTk5OS9YU0wvVHJhbnNmb3JtIgogICAgICAg ICAgICAgICAgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9zdHJpY3QiPgogIDx4 c2w6b3V0cHV0IG1ldGhvZD0iaHRtbCIgaW5kZW50PSJ5ZXMiIGRvY3R5cGUtcHVibGljPSItLy9X M0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwvL0VOIi8+CiAgPCEtLSBQQUdFID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LS0+CiAgPHhz bDp0ZW1wbGF0ZSBtYXRjaD0icGFnZSI+CiAgICA8eHNsOnByb2Nlc3NpbmctaW5zdHJ1Y3Rpb24g bmFtZT0iY29jb29uLWZvcm1hdCI+dHlwZT0idGV4dC9odG1sIjwveHNsOnByb2Nlc3NpbmctaW5z dHJ1Y3Rpb24+CiAgICA8eHNsOmNvbW1lbnQ+CiAgICAgIFhTTCA8eHNsOnZhbHVlLW9mIHNlbGVj dD0ic3lzdGVtLXByb3BlcnR5KCd4c2w6dmVyc2lvbicpIi8+IC8KICAgICAgPHhzbDp2YWx1ZS1v ZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlbmRvcicpIi8+IAogICAgICAoPHhzbDp2 YWx1ZS1vZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlbmRvci11cmwnKSIvPikKICAg IDwveHNsOmNvbW1lbnQ+CiAgICA8aHRtbD4KICAgICAgPGhlYWQ+CiAgICAgICAgPGxpbmsgcmVs PSJzdHlsZXNoZWV0IiB0eXBlPSJ0ZXh0L2NzcyIgaHJlZj0iLi9zdHlsZXNoZWV0cy9qYXZhZG9j Lmh0bWwuY3NzIi8+CiAgICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSIvPgogICAgICAgIDxtZXRhIG5hbWU9 IkF1dGhvciIgY29udGVudD0ie2F1dGhvcnMvYXV0aG9yL0BuYW1lfSIvPgogICAgICAgIDwhLS0g bWV0YSBuYW1lPSJWZXJzaW9uIiBjb250ZW50PSJ7dmVyc2lvbn0iLyAtLT4KICAgICAgICA8dGl0 bGU+CiAgICAgICAgICA8eHNsOnZhbHVlLW9mIHNlbGVjdD0iQHRpdGxlIi8+CiAgICAgICAgPC90 aXRsZT4KICAgICAgPC9oZWFkPgogICAgICA8Ym9keT4KICAgICAgICA8aDE+CiAgICAgICAgICA8 YSBuYW1lPSJ0b3AiPgogICAgICAgICAgICA8eHNsOnZhbHVlLW9mIHNlbGVjdD0iQHRpdGxlIi8+ CiAgICAgICAgICA8L2E+CiAgICAgICAgPC9oMT4KICAgICAgICA8eHNsOmFwcGx5LXRlbXBsYXRl cyBzZWxlY3Q9ImF1dGhvcnMiLz4KICAgICAgICA8eHNsOmFwcGx5LXRlbXBsYXRlcyBzZWxlY3Q9 InNlY3Rpb24iLz4KICAgICAgPC9ib2R5PgogICAgPC9odG1sPgogIDwveHNsOnRlbXBsYXRlPgog IDwhLS0gQVVUSE9SUyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PS0tPgogIDx4c2w6dGVtcGxhdGUgbWF0Y2g9ImF1dGhvcnMiPgogICAgPGRpdj4K ICAgICAgICA8eHNsOmFwcGx5LXRlbXBsYXRlcyBzZWxlY3Q9ImF1dGhvciIvPgogICAgPC9kaXY+ CiAgPC94c2w6dGVtcGxhdGU+CiAgPCEtLSBBVVRIT1IgPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LS0+CiAgPHhzbDp0ZW1wbGF0ZSBtYXRjaD0i YXV0aG9yIj4KICAgIDx4c2w6Y2hvb3NlPgogICAgICA8eHNsOndoZW4gdGVzdD0iQGVtYWlsWy4g IT0gJyddIj4KICAgICAgICA8YSBocmVmPSJtYWlsdG86e0BlbWFpbH0iPgogICAgICAgICAgPGVt PgogICAgICAgICAgICA8eHNsOnZhbHVlLW9mIHNlbGVjdD0iQG5hbWUiLz4KICAgICAgICAgIDwv ZW0+CiAgICAgICAgPC9hPgogICAgICA8L3hzbDp3aGVuPgogICAgICA8eHNsOm90aGVyd2lzZT4K ICAgICAgICA8ZW0+CiAgICAgICAgICA8eHNsOnZhbHVlLW9mIHNlbGVjdD0iQG5hbWUiLz4KICAg ICAgICA8L2VtPgogICAgICA8L3hzbDpvdGhlcndpc2U+CiAgICA8L3hzbDpjaG9vc2U+CiAgICA8 YnIvPgogIDwveHNsOnRlbXBsYXRlPgogIDwhLS0gU0VDVElPTiA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PS0tPgogIDx4c2w6dGVtcGxhdGUgbWF0 Y2g9InNlY3Rpb24iPgogICAgPGgyPjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJAdGl0bGUiLz48L2gy PgogICAgPHhzbDphcHBseS10ZW1wbGF0ZXMgc2VsZWN0PSJwfHNvdXJjZSIvPgogIDwveHNsOnRl bXBsYXRlPgogIDwhLS0gUCA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PS0tPgogIDx4c2w6dGVtcGxhdGUgbWF0Y2g9InAiPgogICAgPGRp diBjbGFzcz0icCI+CiAgICAgIDx4c2w6YXBwbHktdGVtcGxhdGVzLz4KICAgIDwvZGl2PgogIDwv eHNsOnRlbXBsYXRlPgogIDwhLS0gU09VUkNFID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PS0tPgogIDx4c2w6dGVtcGxhdGUgbWF0Y2g9InNvdXJj ZSI+CiAgICA8ZGl2IGNsYXNzPSJzb3VyY2UiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiNFRUVF RUUiPgogICAgICA8cHJlPgogICAgICAgIDx4c2w6dmFsdWUtb2Ygc2VsZWN0PSIuIi8+CiAgICAg IDwvcHJlPgogICAgPC9kaXY+CiAgPC94c2w6dGVtcGxhdGU+CiAgPCEtLSBMSU5LID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09LS0+CiAgPHhz bDp0ZW1wbGF0ZSBtYXRjaD0ibGluayI+CiAgICA8YSBocmVmPSJ7QGhyZWZ9Ij4KICAgICAgPHhz bDphcHBseS10ZW1wbGF0ZXMvPgogICAgPC9hPgogIDwveHNsOnRlbXBsYXRlPgo8L3hzbDpzdHls ZXNoZWV0Pgo= --_=_=_=IMA.BOUNDARY.FLR9JM138764=_=_=_-- From ted@gs2admin1.e-meet.com Thu Nov 25 15:14:38 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 15939 invoked from network); 25 Nov 1999 15:14:38 -0000 Received: from gs2admin1.e-meet.com (38.181.182.4) by taz.hyperreal.org with SMTP; 25 Nov 1999 15:14:38 -0000 Received: from groupserve.com ([38.30.47.98]) by gs2admin1.e-meet.com (Netscape Messaging Server 3.01) with ESMTP id 270 for ; Thu, 25 Nov 1999 10:14:21 -0500 Message-ID: <383D5522.D44690E8@groupserve.com> Date: Thu, 25 Nov 1999 10:26:27 -0500 From: "Ted" X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Complete Headers of Some Browsers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I sent only the user-agent headers before. Here is what is returned by the browser headers (complete). As you can see, the info they return is not uniform --- especially for the language section: 1) Phone.com's UPBrowser Beta 4 for WML/WAP: Accept-Charset=ISO-8859-1 Accept-Language=en Content-Type=application/x-www-form-urlencoded Cookie=jwssessionid=D4FGIPYAAAAAJUNX452AAAA x-up-subno=Administrator_tedtop.groupserve.com x-upfax-accepts=none x-up-uplink=none x-up-devcap-smartdialing=1 x-up-devcap-screendepth=1 x-up-devcap-iscolor=0 x-up-devcap-immed-alert=1 x-up-devcap-numsoftkeys=2 x-up-devcap-screenpixels=171,108 x-up-devcap-msize=8,18 Accept=application/x-hdmlc, application/x-up-alert, application/x -up-cacheop, application/x-up-device, application/x-up-digestentry, text/x-hdml; version=3.1, text/x-hdml;version=3.0, text/x-hdml;version=2.0, text/x-wap.wml, t ext/vnd.wap.wml, */*, image/bmp, text/html User-Agent=UP.Browser/3.1-UPG1 UP.Link/3.2 Host=localhost:8080 2) Nokia's WAP Tookit 1.2 for WML/WAP Cache-Control=no-cache Connection=keep-alive Date=Thu, 25 Nov 1999 15:08:11 GMT Pragma=no-cache Accept=text/vnd.wap.wml,text/vnd.wap.wmlscript,application/vnd.wa p.wmlc, application/vnd.wap.wmlscriptc, image/vnd.wap.wbmp, image/gif Accept-Charset=UTF-8, ISO-8859-1, ISO-10646-UCS-2 Host=localhost:8080 User-Agent=Nokia-WAP-Toolkit/1.2 3) Ericsson's WAPIDE 2.0 Beta 8 for WML/WAP Host=localhost User-Agent=WapIDE-SDK/2.0; (R320s (Arial)) 4) Motorola's Mobile ADK Version 1 Beta 4 for WML/WAP User-Agent=Win32UrlFetcher/1.0 Accept=*/* Host=localhost:8080 Connection=Keep-Alive 5) Motorola's Mobile ADK Version 1 Beta 4 for VML (Voice) User-Agent=Motorola VoxGateway/2.0 Accept=text/x-vxml, */* Host=localhost:8080 Connection=Keep-Alive 6) Here's Microsoft IE 5.0 Accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Accept-Language=en-us Accept-Encoding=gzip, deflate User-Agent=Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) Host=localhost:8080 Connection=Keep-Alive 7) Here's Netscape 4.6 Connection=Keep-Alive User-Agent=Mozilla/4.61 [en] (WinNT; U) Host=localhost:8080 Accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image /png, */* Accept-Encoding=gzip Accept-Language=en Accept-Charset=iso-8859-1,*,utf-8 Cheers! Ted Theodore B. Achacoso, MD http://www.groupvine.com ted@groupserve.com (202) 607-5580 From stefano@apache.org Thu Nov 25 15:48:00 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 764 invoked from network); 25 Nov 1999 15:48:00 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 25 Nov 1999 15:48:00 -0000 Received: from apache.org (pv22-pri.systemy.it [194.21.255.22]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id QAA13862 for ; Thu, 25 Nov 1999 16:47:52 +0100 Message-ID: <383C711A.5132BC86@apache.org> Date: Thu, 25 Nov 1999 00:13:30 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Ant Builder Completed References: <199911241523.QAA85145@stiller.netland.inka.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Hermann wrote: > > Hi! > > This is the completed builder, I changed a few things with regard to > the original ECS way of things, especially the combination of core & > options is automatic. You just have to set the env vars in the .bat > correctly. > > If you CVS add these, please remove my path settings first (JSDK20, and > the optional package paths). > > Ciao, Juergen Thanks Juergen, I'll play around with it to reduce the verbosity (Ant has some nice directory recursion that makes this easier). -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From stefano@apache.org Thu Nov 25 15:48:51 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 2487 invoked from network); 25 Nov 1999 15:48:51 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 25 Nov 1999 15:48:51 -0000 Received: from apache.org (pv22-pri.systemy.it [194.21.255.22]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id QAA13958 for ; Thu, 25 Nov 1999 16:48:31 +0100 Message-ID: <383D44B3.3E8E3106@apache.org> Date: Thu, 25 Nov 1999 15:16:19 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Cocoon on its new home! References: <199911250926.KAA17055@stiller.netland.inka.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Hermann wrote: > > On Wed, 24 Nov 1999 10:57:22 +0100, Stefano Mazzocchi wrote: > > >d) documentation moved to XML > > > > - creation of the "Apache Documentation DTD 1.0a" (still in working > >draft) using "XML Specification DTD v2.0" by Eve Maler > >(elm@arbortext.com) used by W3C to edit their own specifications, plus > >using HTML 4.0 as a reference base for tags. Feedback welcome. > > > > - porting of HTML -> XML for all HTML documentation > > - porting to XML of both changes.xml and todo.xml > > Did you consider DocBook? This is going to be the ultimate FAQ, I can feel that. > Just FYI, it has the advantage that it's > stable and being actively worked on as its own project (you know, > duplication of efforts and all). I evalutated DocBook a while ago, but I found it utterly overcomplex for our needs. On the other hand, what bugged me most is the lack of good tutorial/documentation/examples. Do you have any good pointer for any of those? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From dirkx@webweaving.org Thu Nov 25 16:06:13 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 13237 invoked from network); 25 Nov 1999 16:06:13 -0000 Received: from ns.skylink.it (root@194.177.113.1) by taz.hyperreal.org with SMTP; 25 Nov 1999 16:06:13 -0000 Received: from kim.ispra.webweaving.org (va-164.skylink.it [194.185.55.164]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id RAA25474 for ; Thu, 25 Nov 1999 17:06:39 +0100 Received: from brunte.ispra.webweaving.org (brunte.ispra.webweaving.org [10.0.0.12]) by kim.ispra.webweaving.org (8.8.8/8.8.5) with ESMTP id PAA29693 for ; Thu, 25 Nov 1999 15:57:55 GMT X-Passed: MX on Ispra.WebWeaving.org Thu, 25 Nov 1999 15:57:55 GMT and masked X-No-Spam: Neither the receipients nor the senders email address(s) are to be used for Unsolicited (Commercial) Email without the explicit written consent of either party; as a per-message fee is incurred for inbound and outbound traffic to the originator. Posted-Date: Thu, 25 Nov 1999 15:57:55 GMT Date: Thu, 25 Nov 1999 16:57:55 +0100 (CET) From: Dirk-Willem van Gulik X-Sender: dirkx@brunte.ispra.webweaving.org To: cocoon-dev@xml.apache.org Subject: Re: Complete Headers of Some Browsers In-Reply-To: <383D5522.D44690E8@groupserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 25 Nov 1999, Ted wrote: > I sent only the user-agent headers before. Here is what is returned by > the browser headers (complete). As you can see, the info they return is > not uniform --- especially for the language section: Actaully, note that it _very_ much depends if you go through something 'clever' like the UP.link (as did your UP.Browser request below) or through the nokkia's or errikson's flatter gateways. Or through a direct, say smpp mapper. A pure UP.Browser request is rather sparse. Dw. From ted@gs2admin1.e-meet.com Thu Nov 25 17:21:53 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 18625 invoked from network); 25 Nov 1999 17:21:53 -0000 Received: from gs2admin1.e-meet.com (38.181.182.4) by taz.hyperreal.org with SMTP; 25 Nov 1999 17:21:53 -0000 Received: from groupserve.com ([38.30.47.98]) by gs2admin1.e-meet.com (Netscape Messaging Server 3.01) with ESMTP id 185; Thu, 25 Nov 1999 12:21:37 -0500 Message-ID: <383D72F6.76557151@groupserve.com> Date: Thu, 25 Nov 1999 12:33:42 -0500 From: "Ted" X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cocoon , cocoon-dev@xml.apache.org, george@adiva.com Subject: Re: Complete Headers of Some Browsers References: <383D614D.B7796D61@groupserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, the UPBrowser header data I sent was for SDK3.2. Here's the one for 4.0 beta: Accept-Charset=ISO-8859-1 Accept-Language=en Content-Type=application/x-www-form-urlencoded Cookie=jwssessionid=T4LFRUQAAAAADUNX452AAAA x-up-subno=Administrator_tedtop.groupserve.com x-upfax-accepts=none x-up-uplink=none x-up-devcap-smartdialing=1 x-up-devcap-screen-depth=1 x-up-devcap-has-color=0 x-up-devcap-immed-alert=1 x-up-devcap-num-softkeys=2 x-up-devcap-screen-pixels=171,108 x-up-devcap-em-size=8,18 Accept=application/x-hdmlc, application/x-up-alert, application/x -up-cacheop, application/x-up-device, application/x-up-digestentry, text/x-hdml; version=3.1, text/x-hdml;version=3.0, text/x-hdml;version=2.0, text/x-wap.wml, t ext/vnd.wap.wml, text/vnd.wap.wmlscript, */*, image/bmp, text/html User-Agent=UPG1 UP/4.0.5c Host=localhost:8080 Cheers! Ted Theodore B. Achacoso, MD http://www.groupvine.com ted@groupserve.com (202) 607-5580 Ted wrote: > > This is a cross-post from cocoon-dev@xml.apache.org > > I sent only the user-agent headers before. Here is what is returned by > the browser headers (complete). As you can see, the info they return is > not uniform --- especially for the language section: > > 1) Phone.com's UPBrowser Beta 4 for WML/WAP: > > Accept-Charset=ISO-8859-1 > Accept-Language=en > Content-Type=application/x-www-form-urlencoded > Cookie=jwssessionid=D4FGIPYAAAAAJUNX452AAAA > x-up-subno=Administrator_tedtop.groupserve.com > x-upfax-accepts=none > x-up-uplink=none > x-up-devcap-smartdialing=1 > x-up-devcap-screendepth=1 > x-up-devcap-iscolor=0 > x-up-devcap-immed-alert=1 > x-up-devcap-numsoftkeys=2 > x-up-devcap-screenpixels=171,108 > x-up-devcap-msize=8,18 > Accept=application/x-hdmlc, application/x-up-alert, application/x > -up-cacheop, application/x-up-device, application/x-up-digestentry, > text/x-hdml; > version=3.1, text/x-hdml;version=3.0, text/x-hdml;version=2.0, > text/x-wap.wml, t > ext/vnd.wap.wml, */*, image/bmp, text/html > User-Agent=UP.Browser/3.1-UPG1 UP.Link/3.2 > Host=localhost:8080 > > 2) Nokia's WAP Tookit 1.2 for WML/WAP > > Cache-Control=no-cache > Connection=keep-alive > Date=Thu, 25 Nov 1999 15:08:11 GMT > Pragma=no-cache > Accept=text/vnd.wap.wml,text/vnd.wap.wmlscript,application/vnd.wa > p.wmlc, application/vnd.wap.wmlscriptc, image/vnd.wap.wbmp, image/gif > Accept-Charset=UTF-8, ISO-8859-1, ISO-10646-UCS-2 > Host=localhost:8080 > User-Agent=Nokia-WAP-Toolkit/1.2 > > 3) Ericsson's WAPIDE 2.0 Beta 8 for WML/WAP > > Host=localhost > User-Agent=WapIDE-SDK/2.0; (R320s (Arial)) > > 4) Motorola's Mobile ADK Version 1 Beta 4 for WML/WAP > > User-Agent=Win32UrlFetcher/1.0 > Accept=*/* > Host=localhost:8080 > Connection=Keep-Alive > > 5) Motorola's Mobile ADK Version 1 Beta 4 for VML (Voice) > > User-Agent=Motorola VoxGateway/2.0 > Accept=text/x-vxml, */* > Host=localhost:8080 > Connection=Keep-Alive > > 6) Here's Microsoft IE 5.0 > > Accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* > Accept-Language=en-us > Accept-Encoding=gzip, deflate > User-Agent=Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) > > Host=localhost:8080 > Connection=Keep-Alive > > 7) Here's Netscape 4.6 > > Connection=Keep-Alive > User-Agent=Mozilla/4.61 [en] (WinNT; U) > Host=localhost:8080 > Accept=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image > /png, */* > Accept-Encoding=gzip > Accept-Language=en > Accept-Charset=iso-8859-1,*,utf-8 > > Cheers! > > Ted > Theodore B. Achacoso, MD > http://www.groupvine.com > ted@groupserve.com > (202) 607-5580 > > ---------------------------------------------------------------- > To subscribe: cocoon-on@list.working-dogs.com > To unsubscribe: cocoon-off@list.working-dogs.com > FAQ: > Problems?: jon@working-dogs.com From smuench@us.oracle.com Thu Nov 25 20:41:35 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 25876 invoked from network); 25 Nov 1999 20:41:35 -0000 Received: from inet16.us.oracle.com (209.246.15.50) by taz.hyperreal.org with SMTP; 25 Nov 1999 20:41:35 -0000 Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet16.us.oracle.com (8.9.2/8.8.5) with SMTP id MAA28736 for ; Thu, 25 Nov 1999 12:41:34 -0800 (PST) Received: from smuenchlap by usmail04 with SMTP (SMI-8.6/37.9) id MAA06238; Thu, 25 Nov 1999 12:41:34 -0800 Message-ID: <003401bf3774$b56b10d0$85672382@us.oracle.com> From: "Steve Muench" To: References: <199911250926.KAA17055@stiller.netland.inka.de> <383D44B3.3E8E3106@apache.org> Subject: Re: Cocoon on its new home! Date: Thu, 25 Nov 1999 12:41:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 See: http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html This is Norman Walsh's recently published book on DocBook, entirely online. I consulted his online book frequently for a DocBook-based project I'm working on and it's been invaluable. The fact that he's already built XSLT stylesheets for DocBook->HTML and DocBook->FO's was a big plus. For my project I've created an XSLT stylesheet that does of his, and tweaks a few things I wanted formatted differently. He's really bent-over-backwards to design these XSLT stylesheets in a maximally-overridable way and it shows. Norman Walsh's stuff is at http://www.nwalsh.com _________________________________________________________ Steve Muench, Consulting Product Manager & XML Evangelist Business Components for Java Development Team http://technet.oracle.com/tech/java http://technet.oracle.com/tech/xml ----- Original Message ----- From: Stefano Mazzocchi To: Sent: Thursday, November 25, 1999 8:16 AM Subject: Re: Cocoon on its new home! | Juergen Hermann wrote: | > | > On Wed, 24 Nov 1999 10:57:22 +0100, Stefano Mazzocchi wrote: | > | > >d) documentation moved to XML | > > | > > - creation of the "Apache Documentation DTD 1.0a" (still in working | > >draft) using "XML Specification DTD v2.0" by Eve Maler | > >(elm@arbortext.com) used by W3C to edit their own specifications, plus | > >using HTML 4.0 as a reference base for tags. Feedback welcome. | > > | > > - porting of HTML -> XML for all HTML documentation | > > - porting to XML of both changes.xml and todo.xml | > | > Did you consider DocBook? | | This is going to be the ultimate FAQ, I can feel that. | | > Just FYI, it has the advantage that it's | > stable and being actively worked on as its own project (you know, | > duplication of efforts and all). | | I evalutated DocBook a while ago, but I found it utterly overcomplex for | our needs. | | On the other hand, what bugged me most is the lack of good | tutorial/documentation/examples. Do you have any good pointer for any of | those? | | -- | Stefano Mazzocchi One must still have chaos in oneself to be | able to give birth to a dancing star. | Friedrich Nietzsche | | | From stefano@apache.org Thu Nov 25 22:55:25 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 10909 invoked from network); 25 Nov 1999 22:55:25 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 25 Nov 1999 22:55:25 -0000 Received: from apache.org (pv18-pri.systemy.it [194.21.255.18]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id XAA01048 for ; Thu, 25 Nov 1999 23:55:16 +0100 Message-ID: <383D74DC.59C2580D@apache.org> Date: Thu, 25 Nov 1999 18:41:48 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: XML Icon References: <199911251248.NAA22441@stiller.netland.inka.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Hermann wrote: > > Attached is an icon that can be used as follows with Apache: > > AddIcon /icons/xml.gif .xml .xsl You should send this to new-httpd :) -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From nader@makeit.no Fri Nov 26 07:36:02 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 11464 invoked from network); 26 Nov 1999 07:36:02 -0000 Received: from unknown (HELO home.netti.nu) (root@195.159.89.21) by taz.hyperreal.org with SMTP; 26 Nov 1999 07:36:02 -0000 Received: from nader (mp-217-212-242.daxnet.no [193.217.212.242]) by home.netti.nu (8.9.1/8.9.1) with SMTP id HAA32202; Fri, 26 Nov 1999 07:42:10 +0100 Message-ID: <001a01bf37e9$584b9800$0a26f081@nader> From: "Nader Aeinehchi" To: , "Juergen Hermann" Subject: Re: XML Icon Date: Fri, 26 Nov 1999 09:36:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hello there: I still feel myself stupid: I still do not understand what Cocoon does. I would like to contribute if I get answer to the following questions: 1) There are XML, XSL parsers available. What does Cocoon additionally do? You are already using known parsers. Why a new servlet API? 2) Logicsheets, Templates in the stylesheet? Is this something new? I have not heard it (please forgive me for my ignorance). I appreciate that if someone answers me briefly. Nader Aeinehchi -----Original Message----- From: Juergen Hermann To: Cocoon Developers Date: Thursday, November 25, 1999 4:04 PM Subject: XML Icon >Attached is an icon that can be used as follows with Apache: > >AddIcon /icons/xml.gif .xml .xsl > > From ssahuc@imediation.com Fri Nov 26 09:31:10 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 3868 invoked from network); 26 Nov 1999 09:31:10 -0000 Received: from unknown (HELO ?195.115.98.1?) (195.115.98.1) by taz.hyperreal.org with SMTP; 26 Nov 1999 09:31:10 -0000 Received: from mail.imediation.com by [195.115.98.1] via smtpd (for taz.hyperreal.org [209.133.83.16]) with SMTP; 26 Nov 1999 10:32:28 UT Received: by mail.imediation.com with Internet Mail Service (5.5.2232.9) id ; Fri, 26 Nov 1999 10:28:03 +0100 Message-ID: From: Sebastien Sahuc To: cocoon-dev@xml.apache.org Subject: RE: XML Icon Date: Fri, 26 Nov 1999 10:28:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" > 1) There are XML, XSL parsers available. What does Cocoon > additionally do? Cocoon acts a a publishing framework and relies heavily on XML and XSL processing. Indeed it's a factory that is feeded with XML and XSL documents, in order to generate dynamic-XML at run time before resulting an HTML from the stylesheet processor. > You are already > using known parsers. Why a new servlet API? To deliver dynamic WEB contents. > 2) Logicsheets, Templates in the stylesheet? Is this > something new? I have > not heard it (please > forgive me for my ignorance). Indeed, many people are speaking about JSP, which make few people angry because of it lack of disctinction between the data, the logic and the presentation. That's why cocoon started (at least that's what I think). Sebastien From jh@netland.inka.de Fri Nov 26 10:10:54 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22025 invoked from network); 26 Nov 1999 10:10:54 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 26 Nov 1999 10:10:54 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11rIL2-0006aC-00; Fri, 26 Nov 1999 11:10:48 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id JAA54279 for ; Fri, 26 Nov 1999 09:50:20 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911260850.JAA54279@stiller.netland.inka.de> From: "Juergen Hermann" To: "cocoon-dev@xml.apache.org" Date: Fri, 26 Nov 1999 09:46:50 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: DocBook (was Re: Cocoon on its new home!) On Thu, 25 Nov 1999 15:16:19 +0100, Stefano Mazzocchi wrote: >This is going to be the ultimate FAQ, I can feel that. (c: >I evalutated DocBook a while ago, but I found it utterly overcomplex >for our needs. It sure brings a wealth of markup, which is both a curse and nice to have when you need it. And you can always restrict yourself to a subset. Its advantage is when you once learned it, you can do any technical doc with it. And there is an XML version of it now. What's the worst thing about the Jade/SGML side of things is the setup of the tools, it takes a few hours if you do it the first time and w/o help. And you will have people out there knowing it already, which might attract some documentation volunteers. > >On the other hand, what bugged me most is the lack of good >tutorial/documentation/examples. Do you have any good pointer for any of >those? Norman has released his book, so this is the best you can get: http://docbook.org/tdg/. Ciao, Juergen From jh@netland.inka.de Fri Nov 26 10:10:54 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22024 invoked from network); 26 Nov 1999 10:10:54 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 26 Nov 1999 10:10:54 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11rIL2-0006aA-00; Fri, 26 Nov 1999 11:10:48 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id JAA53766 for ; Fri, 26 Nov 1999 09:30:57 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911260830.JAA53766@stiller.netland.inka.de> From: "Juergen Hermann" To: "cocoon-dev@xml.apache.org" Date: Fri, 26 Nov 1999 09:27:28 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Ant Builder Completed On Thu, 25 Nov 1999 00:13:30 +0100, Stefano Mazzocchi wrote: >Thanks Juergen, I'll play around with it to reduce the verbosity (Ant >has some nice directory recursion that makes this easier). What made it hard is that the optional files are mixed with core files, else I'd have not added the copyfile orgies. If you know a way around this short of restructuring the source tree, all the better. Ciao, Juergen From jh@netland.inka.de Fri Nov 26 10:10:54 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22026 invoked from network); 26 Nov 1999 10:10:54 -0000 Received: from quechua.inka.de (HELO mail.inka.de) (mail@212.227.14.2) by taz.hyperreal.org with SMTP; 26 Nov 1999 10:10:54 -0000 Received: from stiller.netland.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 11rIL2-0006aE-00; Fri, 26 Nov 1999 11:10:48 +0100 Received: from owlglass (owlglass.netland.inka.de [10.1.1.5]) by stiller.netland.inka.de (8.9.3/8.9.3) with SMTP id JAA54527 for ; Fri, 26 Nov 1999 09:55:36 +0100 (CET) (envelope-from jh@netland.inka.de) Message-Id: <199911260855.JAA54527@stiller.netland.inka.de> From: "Juergen Hermann" To: "cocoon-dev@xml.apache.org" Date: Fri, 26 Nov 1999 09:52:05 +0100 Reply-To: "Juergen Hermann" Priority: Normal X-Mailer: PMMail 98 Standard (2.00.1500) For Windows NT (4.0.1381;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Cocoon on its new home! On Thu, 25 Nov 1999 12:41:38 -0600, Steve Muench wrote: >For my project I've created an XSLT stylesheet >that does of his, and tweaks a >few things I wanted formatted differently. I wish I could. Could you tell me which parser/xsl processor combo you use. All my tests to get to work failed so far, and I tried all combinations. Ciao, Juergen From stefano@apache.org Fri Nov 26 17:57:03 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 19326 invoked from network); 26 Nov 1999 17:57:03 -0000 Received: from pop.systemy.it (194.20.140.28) by taz.hyperreal.org with SMTP; 26 Nov 1999 17:57:03 -0000 Received: from apache.org (pv45-pri.systemy.it [194.21.255.45]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id SAA22867 for ; Fri, 26 Nov 1999 18:56:59 +0100 Message-ID: <383E8635.C2758686@apache.org> Date: Fri, 26 Nov 1999 14:08:05 +0100 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: XML Icon References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastien Sahuc wrote: > > You are already > > using known parsers. Why a new servlet API? > > To deliver dynamic WEB contents. Not only that. The current servlet API fails to address the context separation issues that Cocoon addresses and JSP, being servlet API based, follow the same limitations. But to find out more, you have to install it and try it out yourself. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche From smuench@us.oracle.com Fri Nov 26 18:51:08 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 18445 invoked from network); 26 Nov 1999 18:51:08 -0000 Received: from inet16.us.oracle.com (209.246.15.50) by taz.hyperreal.org with SMTP; 26 Nov 1999 18:51:08 -0000 Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet16.us.oracle.com (8.9.2/8.8.5) with SMTP id KAA17670; Fri, 26 Nov 1999 10:51:01 -0800 (PST) Received: from smuenchlap by usmail04 with SMTP (SMI-8.6/37.9) id KAA14482; Fri, 26 Nov 1999 10:51:00 -0800 Message-ID: <00aa01bf382e$70846880$85672382@us.oracle.com> From: "Steve Muench" To: , "Juergen Hermann" References: <199911260855.JAA54527@stiller.netland.inka.de> Subject: Re: Cocoon on its new home! Date: Fri, 26 Nov 1999 10:51:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I use the Oracle XSLT Engine (part of the Oracle XML Parser for Java "v2" download) to do my production work. http://technet.oracle.com/tech/xml From my testing, XT gets the job done, too. Not sure about others as I haven't tried them myself. _________________________________________________________ Steve Muench, Consulting Product Manager & XML Evangelist Business Components for Java Development Team http://technet.oracle.com/tech/java http://technet.oracle.com/tech/xml ----- Original Message ----- From: Juergen Hermann To: Sent: Friday, November 26, 1999 2:52 AM Subject: Re: Cocoon on its new home! | On Thu, 25 Nov 1999 12:41:38 -0600, Steve Muench wrote: | | >For my project I've created an XSLT stylesheet | >that does of his, and tweaks a | >few things I wanted formatted differently. | | I wish I could. Could you tell me which parser/xsl processor combo you | use. All my tests to get to work failed so far, and I | tried all combinations. | | | | | | Ciao, Juergen | | | From pier@apache.org Sat Nov 27 11:03:23 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 2158 invoked from network); 27 Nov 1999 11:03:23 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by taz.hyperreal.org with SMTP; 27 Nov 1999 11:03:23 -0000 Received: from sun(sun.betaversion.org[192.168.1.2]) (1674 bytes) by kali.betaversion.org via smail with P:smtp/R:internet/T:smtp (sender: ) id for ; Sat, 27 Nov 1999 03:06:19 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <01db01bf38c7$71bb2240$0201a8c0@betaversion.org> From: "Pierpaolo Fumagalli" To: References: <383BB682.777AC94A@apache.org> Subject: Re: Cocoon on its new home! Date: Sat, 27 Nov 1999 03:06:24 -0800 Organization: The Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: Stefano Mazzocchi > > - work with Pier on the integration with Stylebook (Pier, what's the > status of StyleBook?) It works perfectly... In the next few weeks we'll have a bunch of new features... - Support for "stylebook" files (archives w/ all things nedeed to process a bunch of XML files and translate it to "*" (want to change style? simply specify a new "stylebook" :) - SAX2 full support... I'm moving the whole thing to the SAX model (i'm done w/ dom... don't let me see it anymore). The only problem w/ that right now is that XALAN does not support it, so, it'll be a small problem :( - Revised styles for XML.APACHE.ORG (regarding the docs my team wrote, we're not abandoning the DTDs of XERCES, we have too many docs written using those DTDs, and we have time <= 0 to change them, the styles and so...) - Fix Fix Fix Fix :) That's it... Pier (back coding!) From pier@apache.org Sat Nov 27 11:08:56 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 4795 invoked from network); 27 Nov 1999 11:08:56 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by taz.hyperreal.org with SMTP; 27 Nov 1999 11:08:56 -0000 Received: from sun(sun.betaversion.org[192.168.1.2]) (1567 bytes) by kali.betaversion.org via smail with P:smtp/R:internet/T:smtp (sender: ) id for ; Sat, 27 Nov 1999 03:11:51 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <01ff01bf38c8$37b66c20$0201a8c0@betaversion.org> From: "Pierpaolo Fumagalli" To: References: <199911250926.KAA17055@stiller.netland.inka.de> <383D44B3.3E8E3106@apache.org> Subject: Re: Cocoon on its new home! Date: Sat, 27 Nov 1999 03:11:56 -0800 Organization: The Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: Stefano Mazzocchi > > I evalutated DocBook a while ago, but I found it utterly > overcomplex for our needs. I spent almost one month crashing my head down on DocBook (when we first thought about StyleBook @ IBM!)... We had the same idea... Too much complexity and too few flexibility... The DTDs we uses for XERCES documentation (and currently for all the XML.APACHE.ORG website), were designed exactly for that. Susan Hardenbrook (our tech writer, who had no experience on XML documentation before), Mike Pogue (my manager), and me designed them to allow untrained people to pick them up easily... We were so much conforted when Andrew (our second tech writer, that just joined our team) picked them up and started using them correctly with basically no training... Our goal was successful :) Pier From pier@apache.org Sat Nov 27 11:14:45 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 7555 invoked from network); 27 Nov 1999 11:14:45 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by taz.hyperreal.org with SMTP; 27 Nov 1999 11:14:45 -0000 Received: from sun(sun.betaversion.org[192.168.1.2]) (1121 bytes) by kali.betaversion.org via smail with P:smtp/R:internet/T:smtp (sender: ) id for ; Sat, 27 Nov 1999 03:17:40 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <000901bf38c9$07f2d540$0201a8c0@betaversion.org> From: "Pierpaolo Fumagalli" To: References: <383BB682.777AC94A@apache.org> <01db01bf38c7$71bb2240$0201a8c0@betaversion.org> Subject: Re: Cocoon on its new home! Date: Sat, 27 Nov 1999 03:17:46 -0800 Organization: The Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: Pierpaolo Fumagalli > > - work with Pier on the integration with Stylebook (Pier, what's the > > status of StyleBook?) > > It works perfectly... > [...] > That's it... No... It's not... (forgot :) The all new XML-(JPG|PNG) translator, using JAI and with a SHITLOAD of improvements :) Pier From john.morrison@experian.com Mon Nov 29 13:50:15 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 13685 invoked from network); 29 Nov 1999 13:50:15 -0000 Received: from mailrelay2.core.theplanet.net (194.152.65.230) by 63.211.145.10 with SMTP; 29 Nov 1999 13:50:15 -0000 Received: from mailhost2.experian.co.uk ([195.92.54.51]) by mailrelay2.core.theplanet.net with esmtp (Exim 2.12 #2) id 11sRBu-0007WI-00 for cocoon-dev@xml.apache.org; Mon, 29 Nov 1999 13:50:06 +0000 Received: from experian.com (unverified) by mailhost2.experian.co.uk (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Mon, 29 Nov 1999 13:51:34 +0000 Received: from UKNOTDT-Message_Server by experian.com with Novell_GroupWise; Mon, 29 Nov 1999 13:50:52 +0000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 29 Nov 1999 13:46:08 +0000 From: John Morrison To: cocoon-dev@xml.apache.org Subject: FOP 0.12.0 released Hi all, Just one small problem, since this is now in the package org.apache.fop It requires more than drop and location change! I can't compile Cocoon, can someone please update the necessary classes and distribute? Thanks, J. From mpogue@apache.org Mon Nov 29 17:48:45 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 18343 invoked from network); 29 Nov 1999 17:48:45 -0000 Received: from ausmail2.austin.ibm.com (192.35.232.11) by 63.211.145.10 with SMTP; 29 Nov 1999 17:48:45 -0000 Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id LAA48220 for ; Mon, 29 Nov 1999 11:45:33 -0600 Received: from popmail.austin.ibm.com (popmail.austin.ibm.com [9.53.247.178]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id LAA13722 for ; Mon, 29 Nov 1999 11:48:42 -0600 Received: from apache.org (socks2.almaden.ibm.com [9.1.40.50]) by popmail.austin.ibm.com (AIX4.2/UCB 8.7/8.7-client1.01) with ESMTP id LAA19000 for ; Mon, 29 Nov 1999 11:48:40 -0600 (CST) Message-ID: <3842BB2D.12AC584B@apache.org> Date: Mon, 29 Nov 1999 09:43:09 -0800 From: Mike Pogue Organization: xml.apache.org X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Cocoon on its new home! References: <199911250926.KAA17055@stiller.netland.inka.de> <383D44B3.3E8E3106@apache.org> <01ff01bf38c8$37b66c20$0201a8c0@betaversion.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree. DocBook is WAY too complex for most needs. BTW, we have about 6 or 8 people using the Stylebook tagset for docs now. Feedback has been good so far. All have ben able to pick it up by example, without any real docs yet. Mike Pierpaolo Fumagalli wrote: > > From: Stefano Mazzocchi > > > > I evalutated DocBook a while ago, but I found it utterly > > overcomplex for our needs. > > I spent almost one month crashing my head down on DocBook (when we first > thought about StyleBook @ IBM!)... We had the same idea... Too much > complexity and too few flexibility... > > The DTDs we uses for XERCES documentation (and currently for all the > XML.APACHE.ORG website), were designed exactly for that. Susan Hardenbrook > (our tech writer, who had no experience on XML documentation before), Mike > Pogue (my manager), and me designed them to allow untrained people to pick > them up easily... > We were so much conforted when Andrew (our second tech writer, that just > joined our team) picked them up and started using them correctly with > basically no training... Our goal was successful :) > > Pier From nader@makeit.no Tue Nov 30 08:45:41 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 32210 invoked from network); 30 Nov 1999 08:45:41 -0000 Received: from home.netti.nu (root@195.159.89.21) by 63.211.145.10 with SMTP; 30 Nov 1999 08:45:41 -0000 Received: from nader (mp-217-227-83.daxnet.no [193.217.227.83]) by home.netti.nu (8.9.1/8.9.1) with SMTP id IAA21605 for ; Tue, 30 Nov 1999 08:50:44 +0100 Message-ID: <001701bf3b17$9192b220$a50a249e@nader.STO.NO> From: "Nader Aeinehchi" To: Subject: Where can I find DocBook /StyleBook@Ibm? Date: Tue, 30 Nov 1999 10:44:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 -----Original Message----- From: Mike Pogue To: cocoon-dev@xml.apache.org Date: Monday, November 29, 1999 7:45 PM Subject: Re: Cocoon on its new home! >I agree. DocBook is WAY too complex for most needs. >BTW, we have about 6 or 8 people using the Stylebook tagset for docs >now. Feedback has been good so far. All have ben able to pick it up by >example, without any real docs yet. > >Mike > >Pierpaolo Fumagalli wrote: >> >> From: Stefano Mazzocchi >> > >> > I evalutated DocBook a while ago, but I found it utterly >> > overcomplex for our needs. >> >> I spent almost one month crashing my head down on DocBook (when we first >> thought about StyleBook @ IBM!)... We had the same idea... Too much >> complexity and too few flexibility... >> >> The DTDs we uses for XERCES documentation (and currently for all the >> XML.APACHE.ORG website), were designed exactly for that. Susan Hardenbrook >> (our tech writer, who had no experience on XML documentation before), Mike >> Pogue (my manager), and me designed them to allow untrained people to pick >> them up easily... >> We were so much conforted when Andrew (our second tech writer, that just >> joined our team) picked them up and started using them correctly with >> basically no training... Our goal was successful :) >> >> Pier > From john.morrison@experian.com Tue Nov 30 12:08:05 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 35957 invoked from network); 30 Nov 1999 12:08:05 -0000 Received: from mailrelayg1.core.theplanet.net (195.92.195.230) by 63.211.145.10 with SMTP; 30 Nov 1999 12:08:05 -0000 Received: from mailhost2.experian.co.uk ([195.92.54.51]) by mailrelayg1.core.theplanet.net with esmtp (Exim 2.12 #2) id 11sm3U-000292-00 for cocoon-dev@xml.apache.org; Tue, 30 Nov 1999 12:06:48 +0000 Received: from experian.com (unverified) by mailhost2.experian.co.uk (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Tue, 30 Nov 1999 12:08:29 +0000 Received: from UKNOTDT-Message_Server by experian.com with Novell_GroupWise; Tue, 30 Nov 1999 12:07:34 +0000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 30 Nov 1999 12:04:06 +0000 From: John Morrison To: cocoon-dev@xml.apache.org Subject: Archive Is there a mail archive (pref searchable?) for the new address/es as I think my servers been bouncing messages :-( Thanks, John. From sidney@krdl.org.sg Tue Nov 30 12:32:00 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 38219 invoked from network); 30 Nov 1999 12:32:00 -0000 Received: from rodin.krdl.org.sg (HELO krdl.org.sg) (192.122.139.27) by 63.211.145.10 with SMTP; 30 Nov 1999 12:32:00 -0000 Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id UAA14605 for ; Tue, 30 Nov 1999 20:38:28 +0800 (SGT) Received: from dino (tptpc4 [192.122.131.29]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id UAA10091 for ; Tue, 30 Nov 1999 20:29:45 +0800 (SGT) Message-ID: <00e601bf3b2e$b86822b0$1d837ac0@krdl.org.sg> From: "Sidney Chong" To: References: Subject: sqlprocessor question Date: Tue, 30 Nov 1999 20:30:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Hi, wondering if anyone can help... I'm trying to use the sqlprocessor but am not successful. The source file and output are as follows: ------------------------------------ input ---------------------------------------------------------------- postgresql.Driver jdbc:postgresql:logdata loguser test My Jobs Hi! This is a test! SELECT * FROM log_data ORDER BY date ------------------------------------ output --------------------------------------------------------------- My Jobs Hi! This is a test! SELECT * FROM log_data ORDER BY date I've setup the driver's classpath and in fact, I am using the same database in a producer. Hence I'm pretty sure the database access is ok. Any ideas? Cheers Sidney From pier@apache.org Tue Nov 30 12:43:29 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 39703 invoked from network); 30 Nov 1999 12:43:29 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by 63.211.145.10 with SMTP; 30 Nov 1999 12:43:29 -0000 Received: from sun(sun.betaversion.org[192.168.1.2]) (884 bytes) by kali.betaversion.org via smail with P:smtp/R:internet/T:smtp (sender: ) id for ; Tue, 30 Nov 1999 04:45:40 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <004901bf3b30$cb354c40$0201a8c0@betaversion.org> From: "Pierpaolo Fumagalli" To: References: <001701bf3b17$9192b220$a50a249e@nader.STO.NO> Subject: Re: Where can I find DocBook /StyleBook@Ibm? Date: Tue, 30 Nov 1999 04:45:34 -0800 Organization: The Apache Software Foundation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 From: Nader Aeinehchi > > [empty] Check out the xml-stylebook module... If all tests are valid, this will be the 1.0, later on, Cocoon :) Pier From stefano@locus.apache.org Tue Nov 30 15:57:54 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 43248 invoked from network); 30 Nov 1999 15:57:54 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 15:57:54 -0000 Received: (qmail 21958 invoked by uid 2016); 30 Nov 1999 15:56:39 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 21946 invoked from network); 30 Nov 1999 15:56:37 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 15:56:37 -0000 Received: (qmail 43215 invoked by uid 1010); 30 Nov 1999 15:56:37 -0000 Date: 30 Nov 1999 15:56:37 -0000 Message-ID: <19991130155637.43214.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/dtd - New directory stefano 99/11/30 07:56:36 xml-cocoon/dtd - New directory From stefano@locus.apache.org Tue Nov 30 15:58:44 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 43286 invoked from network); 30 Nov 1999 15:58:44 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 15:58:44 -0000 Received: (qmail 22239 invoked by uid 2016); 30 Nov 1999 15:57:10 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 22047 invoked from network); 30 Nov 1999 15:56:59 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 15:56:59 -0000 Received: (qmail 43230 invoked by uid 1010); 30 Nov 1999 15:56:59 -0000 Date: 30 Nov 1999 15:56:59 -0000 Message-ID: <19991130155659.43229.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/resources - New directory stefano 99/11/30 07:56:59 xml-cocoon/resources - New directory From stefano@locus.apache.org Tue Nov 30 16:00:11 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 43326 invoked from network); 30 Nov 1999 16:00:11 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 16:00:11 -0000 Received: (qmail 22349 invoked by uid 2016); 30 Nov 1999 15:57:38 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 22312 invoked from network); 30 Nov 1999 15:57:32 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 15:57:32 -0000 Received: (qmail 43246 invoked by uid 1010); 30 Nov 1999 15:57:31 -0000 Date: 30 Nov 1999 15:57:31 -0000 Message-ID: <19991130155731.43245.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/stylesheets - New directory stefano 99/11/30 07:57:31 xml-cocoon/stylesheets - New directory From stefano@locus.apache.org Tue Nov 30 16:03:11 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 43422 invoked from network); 30 Nov 1999 16:03:11 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 16:03:11 -0000 Received: (qmail 27079 invoked by uid 2016); 30 Nov 1999 16:01:49 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 27036 invoked from network); 30 Nov 1999 16:01:48 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 16:01:48 -0000 Received: (qmail 43389 invoked by uid 1010); 30 Nov 1999 16:01:48 -0000 Date: 30 Nov 1999 16:01:48 -0000 Message-ID: <19991130160148.43388.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/resources/orig - New directory stefano 99/11/30 08:01:47 xml-cocoon/resources/orig - New directory From stefano@locus.apache.org Tue Nov 30 16:03:58 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 43453 invoked from network); 30 Nov 1999 16:03:58 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 16:03:58 -0000 Received: (qmail 27834 invoked by uid 2016); 30 Nov 1999 16:02:43 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 27832 invoked from network); 30 Nov 1999 16:02:43 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 16:02:43 -0000 Received: (qmail 43410 invoked by uid 1010); 30 Nov 1999 16:02:42 -0000 Date: 30 Nov 1999 16:02:42 -0000 Message-ID: <19991130160242.43409.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/samples/vml - New directory stefano 99/11/30 08:02:42 xml-cocoon/samples/vml - New directory From stefano@locus.apache.org Tue Nov 30 16:31:30 1999 Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 45330 invoked from network); 30 Nov 1999 16:31:30 -0000 Received: from taz.hyperreal.org (HELO hyperreal.org) (209.133.83.16) by 63.211.145.10 with SMTP; 30 Nov 1999 16:31:30 -0000 Received: (qmail 15048 invoked by uid 2016); 30 Nov 1999 16:30:14 -0000 Delivered-To: apcore-xml-cocoon-cvs@apache.org Received: (qmail 15045 invoked from network); 30 Nov 1999 16:30:13 -0000 Received: from unknown (HELO locus.apache.org) (63.211.145.10) by taz.hyperreal.org with SMTP; 30 Nov 1999 16:30:13 -0000 Received: (qmail 45304 invoked by uid 1010); 30 Nov 1999 16:30:12 -0000 Date: 30 Nov 1999 16:30:12 -0000 Message-ID: <19991130163012.45303.qmail@locus.apache.org> From: stefano@locus.apache.org To: xml-cocoon-cvs@apache.org Subject: cvs commit: xml-cocoon/stylesheets document.css document.html.xsl javadoc.css page.xsl stefano 99/11/30 08:30:11 Modified: . changes.xml todo.xml docs cocoon2.xml dcpprocessor.xml dynamic.xml faq.xml guide.xml index.xml installing.xml license.xml sqlprocessor.xml technologies.xml samples README samples/xsp view-source.xml src/org/apache/cocoon Defaults.java Engine.java Frontend.java cocoon.properties src/org/apache/cocoon/cache CocoonCache.java src/org/apache/cocoon/interpreter/java JavaModule.java src/org/apache/cocoon/parser OpenXMLParser.java Parser.java SunXMLParser.java src/org/apache/cocoon/processor ProcessorFactory.java src/org/apache/cocoon/processor/xslt AbstractXSLTProcessor.java XTProcessor.java src/org/apache/cocoon/producer AbstractProducer.java src/org/apache/cocoon/store MemoryStore.java Added: . build.xml docs WD-xsp.xml javadoc.xml dtd changes-v10.dtd characters.ent document-v10.dtd faq-v10.dtd javadoc-v04draft.dtd specification-v10.dtd todo-v10.dtd resources cocoon-small.jpg cocoon.jpg logo.gif pyramid-model.gif schema.jpg resources/orig powered by cocoon.psd pyramid model of contracts.ai samples/dcp sample-page-html.xsl samples/dcp/ecmascript sample-page.xml samples/dcp/java sample-page.xml samples/fo darkness-novel.xml novel-fo.xsl test-fo.xml samples/hello hello-page-html.xsl hello-page.xml samples/sites/java.apache.org fancy-page-html.xsl news-page.xml text-page-html.xsl samples/sql database-page.xml samples/vml hello-page-vml.xsl hello-page.xml samples/wap example-portfolio.xml portfolio-html.xsl portfolio-wml.xsl src Manifest.mf src/org/apache/cocoon/formatter AbstractFormatter.java FO2PDFFormatter.java HTMLFormatter.java TextFormatter.java VRMLFormatter.java WMLFormatter.java XMLFormatter.java src/org/apache/cocoon/parser AbstractParser.java XercesParser.java src/org/apache/cocoon/processor/xslt XalanProcessor.java stylesheets document.css document.html.xsl javadoc.css page.xsl Removed: docs/api index.html docs/dtd blocks.ent changes.dtd characters.ent faq.dtd page.dtd todo.dtd docs/images cocoon-small.jpg cocoon.jpg logo.gif pyramid-model.gif schema.jpg docs/images/orig powered by cocoon.psd pyramid model of contracts.ai docs/javadoc Engine_java.txt Engine_xml.txt index.html javadoc.dtd javadoc_dtd.txt docs/stylesheets javadoc.html.css docs/xsp WD-xsp.html samples/dcp sample.page.xhtml.xsl samples/dcp/ecmascript sample.page.xml samples/dcp/java sample.page.xml samples/fo darkness.novel.xml novel.fo.xsl test.fo.xml samples/hello hello.page.xhtml.xsl hello.page.xml samples/sites/java.apache.org fancy.page.xhtml.xsl news.page.xml text.page.xhtml.xsl samples/sql database.page.xml samples/wap example.portfolio.xml portfolio.html.xsl portfolio.wml.xsl src MANIFEST Makefile src/org/apache/cocoon/formatter OpenXMLFormatter.java XSLPFormatter.java src/org/apache/cocoon/formatter/html OpenXMLHTMLFormatter.java XSLPHTMLFormatter.java src/org/apache/cocoon/formatter/image NRGFormatter.java src/org/apache/cocoon/formatter/java XSPFormatter.java src/org/apache/cocoon/formatter/pdf FOPFormatter.java src/org/apache/cocoon/formatter/wml OpenXMLWMLFormatter.java XSLPWMLFormatter.java src/org/apache/cocoon/formatter/xhtml OpenXMLXHTMLFormatter.java XSLPXHTMLFormatter.java src/org/apache/cocoon/formatter/xml OpenXMLXMLFormatter.java XSLPXMLFormatter.java src/org/apache/cocoon/parser IBMXMLParser.java OracleXMLParser.java src/org/apache/cocoon/processor/xslt LotusXSLProcessor.java OracleXSLProcessor.java Log: All a bunch of changes. Actually this is an import more than a commit. Make sure you do a fresh checkout since many things has changed. Revision Changes Path 1.2 +370 -226 xml-cocoon/changes.xml Index: changes.xml =================================================================== RCS file: /home/cvs/xml-cocoon/changes.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- changes.xml 1999/11/20 01:11:56 1.1 +++ changes.xml 1999/11/30 16:29:50 1.2 @@ -1,261 +1,405 @@ - + - + + + + + + + - - - - - - - Removed all old PI formats from docs and properties file - - - Added a public method to FormatterFactory to allow more direct formatting - - - Patched EngineWrapper to allow FileProducer to work when called from command line. - + + + Fixed null problem in MemoryStore for command line operation. + + + Added Ant build file. + + + Added Documentation DTD. + + + Added Documentation DTD. + + + Moved "examples/" under "samples/" for global xml.apache.org pattern. + + + Moved "examples/" under "samples/" for global xml.apache.org pattern. + + + Removed the makefile and moved to Ant as building system. + + + Moved all documentation and util files (todo, changes) to XML. + + + Updated support for Sun ProjectX TR2. + + + Updated the parser interface to allow better entity evaluation. :) + + + Added Xerces and Xalan support which now become the default components (finally!). :) + + + Removed XML4j and LotusXSL support. + + + Removed support for Oracle products since it was too difficult to maintain it due to + requirement that Oracle XSLT processor worked on Oracle own DOM implementation. + + + Added VoiceML sample file. + + + Removed all old PI formats from docs and properties file. + + + Added a public method to FormatterFactory to allow more direct formatting. + + + Patched EngineWrapper to allow FileProducer to work when called from command line. + -

Cocoon 1.5 - October 29, 1999
-(Stefano Mazzocchi [SM], Donald -Ball, Kenneth Murphy, Stefano -Malimpensa [SM2]) -

    -
  • Fixed concurrency problem in XML4j parser. Again thanks to Jeffrey Thomas - Harris for the info (SM)
    • -
  • Added JRun installation instructions. Thanks to Scott Stirling - for this (SM)
    • -
  • Added more info on the Cocoon status page. Thanks to David - Lehn for the patch. (SM)
    • -
  • Patched OpenXML that had a bug in the XML publisher that didn't support doctypes imposed from the - outside. This was breaking the WML formatter. (SM)
    • -
  • Patched XSL:P to support <xsl:processing-instruction> instead of - <xsl:pi> which is now deprecated. + + + Fixed concurrency problem in XML4j parser. + + + Added JRun installation instructions. + + + Added more info on the Cocoon status page. + + + Patched OpenXML that had a bug in the XML publisher that didn't support doctypes imposed from the + outside. This was breaking the WML formatter. + + + Patched XSL:P to support <xsl:processing-instruction> instead of <xsl:pi> which is now deprecated. This makes XSL:P a hybrid between XSLT revisions but it's easier this way than to create two sets - of examples that work with latest and oldest releases of XSLT. Hopefully XSLT will standardize soon. (SM)
    • -
  • Fixed XML4J support bug. Thanks to Jeffrey Thomas Harris - for the patch (SM)
    • -
  • Added XSL:P Formatters (SM)
    • -
  • Updated XSL:P to build 19991017 (SM)
    • -
  • Added parameter visibility to formatters to allow request-dependent - formatting. Thanks to Ben Laurie for - the suggestion (SM)
    • -
  • Changed Hashtable in more abstract Dictionary in all interfaces (this will - be updated to collection classes when JDK 1.2 is available) (SM)
    • -
  • Updated Fop to version 0.11 (SM)
    • -
  • Added a work-around for the JServ1.1b2 bug (SM2)
    • -
  • Updated documentation (SM)
    • -
  • Added the plan for JavaDOC XML generator and the JavaDOC DTD working draft - (KM)
    • -
  • Updated examples, especially the WML example which was based on an - obsolete WML DTD (SM)
    • -
  • Added WML formatter (SM)
    • -
  • Added the ability to "mount" the Cocoon status to a configurable - URL (SM)
    • -
  • Added the ability to hide Cocoon status for security reasons (SM)
    • -
  • Removed the persistent part of the object store since it's not used (SM)
    • -
  • Fixed DCP problem in loading the initScript.es file as system resource - (SM)
    • -
  • Added some better diagnostic hooks. Thanks to Ben - Laurie for the patch (SM)
    • -
  • Added SQLProcessor (DB)
    • -
  • Fixed a bug in the EcmaScript language interpreter.(SM2)
    • -
  • Fixed problems on startup without complete configurations and written more - descriptive error messages on exceptions. (SM)
    • -
  • Updated the examples to reflect the changes. (SM)
    • -
  • Changed Cocoon illegal PIs from <?cocon:xxx?> to <?cocoon-xxx?>. - Thanks to Tim Bray for his advice - (SM)
    • -
-

Cocoon 1.4 - September 13 1999
-(Stefano Mazzocchi, James -Tauber, Paul O'Rorke, Ricardo -Rocha, Christopher Conway, Keith -Visco, Hannes Haug) -

    -
  • Fixed portability issues with JRun and Sun's JSWDK. (HH)
    • -
  • Added parsed stylesheets caching capabilities to the AbstractXSLTProcessor: + of examples that work with latest and oldest releases of XSLT. Hopefully XSLT will standardize soon. + + + Fixed XML4J support bug. + + + Added XSL:P Formatters. + + + Updated XSL:P to build 19991017. + + + Added parameter visibility to formatters to allow request-dependent formatting. + + + Changed Hashtable in more abstract Dictionary in all interfaces (this will + be updated to collection classes when JDK 1.2 is available). + + + Updated Fop to version 0.11 + + + Added a work-around for the JServ1.1b2 bug. + + + Updated documentation. + + + Added the plan for JavaDOC XML generator and the JavaDOC DTD working draft. + + + Updated examples, especially the WML example which was based on an obsolete WML DTD. + + + Added WML formatter. + + + Added the ability to "mount" the Cocoon status to a configurable URL. + + + Added the ability to hide Cocoon status for security reasons. + + + Removed the persistent part of the object store since it's not used. + + + Fixed DCP problem in loading the initScript.es file as system resource. + + + Added some better diagnostic hooks. + + + Added SQLProcessor. + + + Fixed a bug in the EcmaScript language interpreter. + + + Fixed problems on startup without complete configurations and written more + descriptive error messages on exceptions. + + + Updated the examples to reflect the changes. + + + Changed Cocoon illegal PIs from <?cocon:xxx?> to <?cocoon-xxx?>. + + + + + + Fixed portability issues with JRun and Sun's JSWDK. + + + Added parsed stylesheets caching capabilities to the AbstractXSLTProcessor: now if produced files are changed but stylesheets don't, the second are not reparsed, improving the system performance since this is a very frequent - case (SM) 
    • -
  • Reduced the memory footprint of some classes by initializing the - hashtables to lower values than default (SM)
    • -
  • Improved the speed of PI searching by looking for first found PI instead - of scanning the whole file (SM)
    • -
  • Updated the cocoon processing instructions that drive the reaction: <?cocoon:process?> - drives the processing reaction, <?cocoon.format?> indicates the - formatter used to end processing and format the document (SM)
    • -
  • Removed the processor pipeline and replaced with a reactor-type router - with PI-based reaction. (SM)
    • -
  • Moved the example classes in their own package for easier installation and - testing (SM) 
    • -
  • Modified a number of classes to fit the new Store and Cache subframeworks. - (SM)
    • -
  • Added a first implementation of the Cache interface based on dynamic - evaluation of changeable points. Since each page is created by different - logic blocks, each one is treated as a changeable point and queried - for change at request time. This allows the page to be recreated if one of - the changeable points changes. (SM)
    • -
  • Added a first implementation of the Store interface based on serialization - persistency wrapped by an adaptively managed memory buffer. The object - storage system is used by the Cache system and its ready for long-living - objects such as compiled pages and such that should survive the JVM - shutdown. (SM)
    • -
  • Added support for the Oracle XSL Processor (works only with the Oracle XML - Parser) (SM)
    • -
  • Added the Store framework (SM)
    • -
  • Included FOP Version 0.9.1 that partially supports latest XSL Formatting - Object specification (19990421) (JT)
    • -
  • Included XSL:P Version 1.0 Beta (19990823) that supports latest XSLT - specification (19990421) (KV)
    • -
  • Introduced the Actor/Director concept to allow cleaner implementation and - configuration of dynamically loaded objects. (SM)
    • -
  • Added the WAP example to show how Cocoon can serve the same content to fat + case. + + + Reduced the memory footprint of some classes by initializing the + hashtables to lower values than default. + + + Improved the speed of PI searching by looking for first found PI instead + of scanning the whole file. + + + Updated the cocoon processing instructions that drive the reaction: <?cocoon:process?> + drives the processing reaction, <?cocoon.format?> indicates the + formatter used to end processing and format the document. + + + Removed the processor pipeline and replaced with a reactor-type router + with PI-based reaction. + + + Moved the example classes in their own package for easier installation and testing. + + + Modified a number of classes to fit the new Store and Cache subframeworks. + + + Added a first implementation of the Cache interface based on dynamic + evaluation of changeable points. + + + Added a first implementation of the Store interface based on serialization + persistency wrapped by an adaptively managed memory buffer. + + + Added support for the Oracle XSL Processor (works only with the Oracle XML Parser). + + + Added the Store framework. + + + Included FOP Version 0.9.1 that partially supports latest XSL Formatting + Object specification (19990421). + + + Included XSL:P Version 1.0 Beta (19990823) that supports latest XSLT + specification (19990421). + + + Introduced the Actor/Director concept to allow cleaner implementation and + configuration of dynamically loaded objects. + + + Added the WAP example to show how Cocoon can serve the same content to fat HTML clients and thin WML clients such as WAP-enabled cellular phones or PDA. - (SM).
    • -
  • Removed the need for a properties file in DCP (SM)
    • -
  • Fixed a minor bug in Configurations. (HH)
    • -
  • Added the Producer subframework for easier dynamic XML generation (SM)
    • -
  • Rewrote and cleaned up the formatting section using the Router abstract - class (SM)
    • -
  • Rewrote some of the underlying design pattern implementations (SM)
    • -
  • Fixed bug in SunXMLParser not implementing Status (CC)
    • -
  • Added support for Oracle XML parser (CC)
    • -
  • Added Dynamic Content Processor (RR)
    • -
  • Updated sample configurations to reflect the changes (SM)
    • -
  • Rewrote the PI parser for more general use in AbstractXSLProcessor (SM)
    • -
  • Created the EngineWrapper class to extend the Engine class for use on - non-servlet based applications. (SM)
    • -
  • Added the possibility to use request parameters to trigger special events - on the page. Currently debug and cache are supported (SM)
    • -
  • Added request and cache as parameters for the processor chain as requested - by more sophisticated processors (SM)
    • -
  • Changed the cache system interface to match new needs (SM) [note: the - cache system has not been yet ported]
    • -
  • Changed the printing architecture. Now, you don't need to specify the type + + + Removed the need for a properties file in DCP. + + + Fixed a minor bug in Configurations. + + + Added the Producer subframework for easier dynamic XML generation. + + + Rewritten and cleaned up the formatting section using the Router abstract class. + + + Rewritten some of the underlying design pattern implementations. + + + Fixed bug in SunXMLParser not implementing Status. + + + Added support for Oracle XML parser. + + + Added Dynamic Content Processor. + + + Updated sample configurations to reflect the changes. + + + Rewritten the PI parser for more general use in AbstractXSLProcessor. + + + Created the EngineWrapper class to extend the Engine class for use on + non-servlet based applications. + + + Added the possibility to use request parameters to trigger special events + on the page. Currently debug and cache are supported. + + + Added request and cache as parameters for the processor chain as requested + by more sophisticated processors. + + + Changed the cache system interface to match new needs. + + + Changed the printing architecture. Now, you don't need to specify the type of formattation but the publishing system will understand it for you (based - on processing instructions and the specified document type) (SM)
    • -
  • Added white paper on the Cocoon 2 architecture for public review (SM)
    • -
  • Fixed typos, added support for more detailed verbosity and fixed a - path-parsing bug for win32 systems (PO)
    • -
  • Added support for James Tauber's FOP to translate XSL:FO-styled documents - into PDF documents (JT, SM)
    • -
-

Cocoon 1.3.1 - May 31 1999
-(Donald Ball, Stefano -Mazzocchi) -

    -
  • Added the first finished working draft of the XSP specification for public - review (SM)
    • -
  • Removed the XML and XSL specifications from the distribution (SM)
    • -
  • Fixed a deadlock problem in the cache system (DB)
    • -
-

Cocoon 1.3 - May 12 1999
-(Donald Ball, Stefano -Mazzocchi, Robb Shecter) -

    -
  • Included more detailed example of future XSP technology (under examples/xsp). - Note: the Cocoon 1.x generation will not support XSP and they are currently - being designed. A very very early access of the working draft is available - under docs/xsp (SM)
    • -
  • Patched the Sun ProjectX parser wrapper to work with latest release. Added - also a Sun printer class (RS)
    • -
  • Added the ability to call Cocoon from the command line (DB and SM)
    • -
  • Fixed the final Vector.toString() problem in JDK 1.1 compilation (SM)
    • -
  • Fixed the "verify error" by using Jikes compiler for - distribution (SM)
    • -
  • Cleaned up documentation and added some entries in the FAQ (SM)
    • -
  • Removed win32 batch scripts and rewritten the makefile (SM)
    • -
  • Added a better cache engine (DB)
    • -
-

Cocoon 1.2 - Apr 30 1999
-(Stefano Mazzocchi, Donald -Ball) -

    -
  • Improved documentation and cleaned things around (SM)
    • -
  • Changed versions of both OpenXML and XSL:P (SM)
    • -
  • Moved the core processing into a different class named Engine, first step - to a complete servlet/application duality (SM)
    • -
  • Added the Cocoon status handler (SM)
    • -
  • Added a better user interface for the servlet and a nicer look to report - errors (SM)
    • -
  • Added the OpenXML printer wrapper class that uses the new X3P API (DB)
    • -
  • Changed the initialization section to match exceptions thrown on different - servlet platforms (SM).
    • -
  • Changed behavior to identity transformation through the DOM processors if - no PI are found. Thanks to George T. - Talbot for pointing it out (SM)
    • -
-

Cocoon 1.1.1 - Apr 5 1999
-(Greg Ritter, Adrian -Durkin, Stefano Mazzocchi) -

    -
  • Fixed a problem with the getClassloader() method returning null. Now + on processing instructions and the specified document type). + + + Added white paper on the Cocoon 2 architecture for public review. + + + Fixed typos, added support for more detailed verbosity and fixed a + path-parsing bug for win32 systems. + + + Added support for James Tauber's FOP to translate XSL:FO-styled documents + into PDF documents. + + + + + + Added the first finished working draft of the XSP specification for public review. + + + Removed the XML and XSL specifications from the distribution. + + + Fixed a deadlock problem in the cache system. + + + + + + Included more detailed example of future XSP technology. + + + Patched the Sun ProjectX parser wrapper to work with latest release. Added also a Sun printer class. + + + Added the ability to call Cocoon from the command line. + + + Fixed the final Vector.toString() problem in JDK 1.1 compilation. + + + Fixed the "verify error" by using Jikes compiler for distribution. + + + Cleaned up documentation and added some entries in the FAQ. + + + Removed win32 batch scripts and rewritten the makefile. + + + Added a better cache engine. + + + + + + Improved documentation and cleaned things around. + + + Changed versions of both OpenXML and XSL:P. + + + Moved the core processing into a different class named Engine, first step + to a complete servlet/application duality. + + + Added the Cocoon status handler. + + + Added a better user interface for the servlet and a nicer look to report errors. + + + Added the OpenXML printer wrapper class that uses the new X3P API. + + + Changed the initialization section to match exceptions thrown on different + servlet platforms. + + + Changed behavior to identity transformation through the DOM processors if + no PI are found. + + + + + + Fixed a problem with the getClassloader() method returning null. Now Cocoon doesn't always use the internal properties file but adds hardcoded default values. This is because in Java 1.1 there is no getSystemClassloader() - method (SM).
    • -
  • Included the updated versions of both OpenXML 1.0.5 and XSL:P 19990326 - which should fix lots of bugs and improve the overall performance (SM)
    • -
  • Patched to avoid the use of File.toURL() method which is not found under - the Java1 platform (SM, thanks to AD)
    • -
  • Added DoNothingCache to avoid caching during document debugging (GR)
    • -
- - - - - - - + method. + + + Included the updated versions of both OpenXML 1.0.5 and XSL:P 19990326 + which should fix lots of bugs and improve the overall performance. + + + Patched to avoid the use of File.toURL() method which is not found under + the Java1 platform. + + + Added DoNothingCache to avoid caching during document debugging. + + + + Changed the stylesheet mapping processing instruction from illegal "xml:stylesheet" - to standard "xml-stylesheet" + to standard "xml-stylesheet". - Created Cocoon logo + Created Cocoon logo. - - Added LRU caching (both memory and disk) + + Added LRU caching (both memory and disk). - Added support for XSL:P processor + Added support for XSL:P processor. - Removed support for Koala XSL parser + Removed support for Koala XSL parser. - Redesigned internal framework + Redesigned internal framework. - Fixed some typos and English bugs in docs + Fixed some typos and English bugs in docs. - - - - - + - Initial version + Initial version. - - - - - - - - - - - - + \ No newline at end of file 1.2 +45 -27 xml-cocoon/todo.xml Index: todo.xml =================================================================== RCS file: /home/cvs/xml-cocoon/todo.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- todo.xml 1999/11/20 01:12:00 1.1 +++ todo.xml 1999/11/30 16:29:50 1.2 @@ -1,58 +1,76 @@ - + - + - - Finish XML-ize the docs (changes.xml and faq.xml). + + + + + + + + + + + Finish XML-ize the docs (xsp-spec). - - Write the stylesheets for the docs. - - - - Add support for Xalan e Xerces and new FOP. + + Write the stylesheets for the docs and traslations to stylebook DTD. - - support external entities with relative URIs + + Integrate docs with xml.apache.org. - + pass request/session parameters to the XSLT processors for dynamic - stylesheet operation + stylesheet operation. - + + Finish Ant makefile to build instead of makefile. + + + Make sure you removed all the java.apache.org instances around. + + + + + + Write SiteMap document. + - + Play around with Tomcat. - + Add the Cocoon2 branch with the Kali sources. - + Add the XSP compiler. - - Write the NRG DTD WD and try to implement a formatter for this. (should we - create its own project? include with FOP?) + + Merge stylebook technology with Cocoon + + - + + + make the error page formatted with the wanted mime type and not only HTML (probably impossible in Cocoon1 model) - - - - Use Ant to build instead of makefile. - + 1.1 xml-cocoon/build.xml Index: build.xml =================================================================== Copyright © ${YEAR} Apache XML Project. All Rights Reserved." /> 1.2 +73 -55 xml-cocoon/docs/cocoon2.xml Index: cocoon2.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/cocoon2.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- cocoon2.xml 1999/11/20 01:16:16 1.1 +++ cocoon2.xml 1999/11/30 16:29:51 1.2 @@ -1,13 +1,17 @@ - + - - - - + +
+ Cocoon 2 + + + +
-
+ +

The Cocoon Project has gone a long way since it's creation on January 1999. It started as a simple servlet for static XSL styling and became more and more powerful as new features were added. Unfortunately, design @@ -26,9 +30,9 @@

In an era where services rather than software will be key for economical success, a better and less expensive model for web publishing will be a winner, especially if based on open standards.

-
+ -
+

Web serving environments must be fast and scalable to be useful. Cocoon1 was born as a "proof of concept" rather than a production software and had significant design restrictions based mainly on @@ -57,43 +61,48 @@ formatted in the response stream. This has significant impacts on performance and memory needs:

- - -

incremental operation: the response is created +

    +
  • + incremental operation: the response is created during document production. Client's perceived performance is dramatically improved since clients can start receiving data as soon as it is created, not after all processing stages have been performed. In those cases where incremental operation is not possible (for example, element sorting), internal buffers store the events until the operation can be performed. However, even in these cases performance can be increased with the use of - tuned memory structures. - -

    lowered memory consumption: since most of the + tuned memory structures. +

    • +
  • + lowered memory consumption: since most of the server processing required in Cocoon is incremental, an incremental model allows XML production events to be transformed directly into output events and character written on streams, thus avoiding the need to store them in - memory. - -

    easier scalability: reduce memory needs allow more + memory. +

    • +
  • + easier scalability: reduce memory needs allow more concurrent operation to be possible, thus allowing the publishing system - to scale as the load increases. - -

    more optimizable code model: modern virtual + to scale as the load increases. +

    • +
  • + more optimizable code model: modern virtual machines are based on the idea of hot spots, code fragments that are used often and, if optimized, increase the process execution by far. This new event model allows easier detection of hot spots since it's a method driven operation, rather than a memory driven one. Hot methods can - be identified earlier and their optimization performed better. - -

    reduced garbage collection: even the most advanced + be identified earlier and their optimization performed better. +

    • +
  • + reduced garbage collection: even the most advanced and lightweight DOM implementation require at least three to five times (and sometimes much more than this) more memory than original document size. This does not only reduce the scalability of the operation, but also impact overall performance by increasing the number of memory garbage that must be collected after the response in sent to the client. Even if modern virtual machines reduced the overhead of garbage collection, less garbage - will always have performance and scalability impacts. - + will always have performance and scalability impacts. +
    • +

The above points, alone, would be enough for the Cocoon2 paradigm shift, even if this event based model impacts not only the general @@ -102,9 +111,9 @@ require substantial work and maybe design reconsideration to be able to follow a pure event-based model. The Cocoon Project will work closely with the other component projects to be able to influence their operation in this direction.

-
+ -
+

Another design choice that should be revised is the reactor pattern that was introduced to allow components to be connected in more flexible way. In fact, opposed to the fixed pipe model used up to Cocoon @@ -119,9 +128,9 @@

But even if the technical difficulties are solved, a key limitation remains: there is no single point of management.

-
+ -
+

The web was created to reduce information management costs by distributing them back on information owners. While this model is great for user communities (scientists, students, employees, or people in general) each @@ -153,38 +162,46 @@

The model that Cocoon2 adopts is the "pyramid model of web contracts" which is outlined in the picture below

- +

The Cocoon2 Pyramid Model of Contracts

and is composed by four different working contexts (the rectangles)

- - +
+
Management
+
the people that decide what the site should - contain, how it should behave and how it should appear - + contain, how it should behave and how it should appear +
+
Content
+
the people responsible to write, own and manage the site content. This context may contain several sub-contexts one - for each language used to express page content. - + for each language used to express page content. +
+
Logic
+
the people responsible for integration with dynamic - content generation technologies and database systems. - + content generation technologies and database systems. +
+
Style
+
the people responsible for information - presentation, look & feel, site graphics and its maintenance. - + presentation, look & feel, site graphics and its maintenance. +
+

and five contracts contexts (the lines)

- - management - content - management - logic - management - style - content - logic - content - style - -
+
    +
  • management - content
    • +
  • management - logic
    • +
  • management - style
    • +
  • content - logic
    • +
  • content - style
    • +
+ -
+

The above model can be applied only if the different contexts never overlap, otherwise there is no chance of having a single management point. For example, if the W3C-recommended method to link stylesheets to XML @@ -214,9 +231,9 @@ into processors directly (XSLT stylesheet compilation) or compiled into producers using logicsheets and XSP which will remove totally the need for request-time interpretation solutions like DCP that will be removed.

-
+ -
+

The cache system in Cocoon1 will be ported with no important design changes since it's very flexible and was not polluted by early design constraints since it appeared in later versions. The issue regards static file @@ -242,14 +259,15 @@

Also, it will be possible to avoid on-fly page and stylesheet compilation (which make debugging harder) with command line pre-compilation hooks that will work like normal compilers from a developer's point of view.

-
+ -
+

Cocoon2 is a big and very ambitious project, not only for the technological issues involved (which will require strong integration with XML components) but also for the significant paradigm shifts imposed by the new technologies. On the other hand, we strongly believe this to be the winner model for future web engineering and if you believe in this yourself, we invite you to join us or help us in any way you can provide.

-
- + + + 1.2 +14 -9 xml-cocoon/docs/dcpprocessor.xml Index: dcpprocessor.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/dcpprocessor.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- dcpprocessor.xml 1999/11/20 01:16:18 1.1 +++ dcpprocessor.xml 1999/11/30 16:29:51 1.2 @@ -1,13 +1,18 @@ - + - - - - + +
+ DCPProcessor User Guide + + + +
-
-

Yet to be XML-ized!

-
- \ No newline at end of file + + +

Yet to be XML-ized!

+ + + \ No newline at end of file 1.2 +67 -63 xml-cocoon/docs/dynamic.xml Index: dynamic.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/dynamic.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- dynamic.xml 1999/11/20 01:16:19 1.1 +++ dynamic.xml 1999/11/30 16:29:51 1.2 @@ -1,21 +1,25 @@ - + - - - - - -
+ +
+ Dynamic XML in Cocoon + + + +
+ + +

Web publishing is very limited without the ability to create dynamic content. For dynamic XML we refer to the content that is created as a function of request parameters or state of the requested resource. For this reason, a lot of work and design has been put into Cocoon to allow dynamic XML content to be generated.

-
+ -
+

People are used to write small Java programs to create their dynamic web content. Servlets, and Java in general, are very powerful, easy to write and fast to debug, but they impose (like any other pure-logic solution) @@ -36,9 +40,9 @@ dynamic XML content would be the perfect choice, unfortunately design issues impose that we take a second look to the technology and understand why this isn't so.

-
+ -
+

Java Servlets were introduced by the Java Web Server team as a way to allow users to create their own web plug-ins. They were designed to handle the HTTP protocol and all possible dynamic web content (including @@ -57,9 +61,9 @@ include a servlet output inside its own transparently. This allowed programmers to separate different logic on different servlets, thus removing the need for servlet chaining

-
+ -
+

While servlet nesting was a major advantage over servlet chaining because it allowed servlets to be somewhat modular without loosing the full API power, a common design pattern applies to the Servlet model in @@ -74,9 +78,9 @@

In a few words, the Servlet API doesn't support Servlet Piping.

-
+ -
+

Rather than turning Cocoon into a servlet engine, thus limiting its portability, this documents outlines some solutions that allow Cocoon users to get the servlet-equivalent functionality with internal Cocoon @@ -84,20 +88,20 @@

The Cocoon processing model is based on the separation of

- - where XML content is generated based on Request parameters (servlet equivalent) - where the produced XML content is transformed/evaluated - where the XML content is finally formatted into the wanted output format for client use. - +
    +
  • Productionwhere XML content is generated based on Request parameters (servlet equivalent)
    • +
  • Processingwhere the produced XML content is transformed/evaluated
    • +
  • Formattingwhere the XML content is finally formatted into the wanted output format for client use.
    • +

This separation of working contexts allows Cocoon users to implement their own internal modules to add the functionality they require to the whole publishing system. In fact, while a few of these components are already shipped with Cocoon, the highly modular structure allows you to build your own to fit your particular needs.

-
+ -
+

Producers initiate the request handling phase. They are responsible to evaluate the HttpServletRequest parameters provided and create XML content that is fed into the processing reactor. A servlet logic should be @@ -108,16 +112,16 @@

Here follows the code for an example producer distributed with Cocoon:

- public class DummyProducer extends AbstractProducer implements Status { - String dummy = "" - + "" - + "" - + "

" + String dummy = "<?xml version=\"1.0\"?>" + + "<?cocoon:format type=\"text/html\"?>" + + "<html><body>" + + "<h1 align=\"center\">" + "Hello from a dummy page" - + "

" - + ""; + + "</h1>" + + "</body></html>"; public Reader getStream(HttpServletRequest request) throws IOException { return new StringReader(dummy); @@ -131,7 +135,7 @@ return "Dummy Producer"; } } -]]> +

The key method is getStream() which is responsible to create process the given servlet request and provide an output stream for reading the @@ -142,11 +146,11 @@ you servlet code Cocoon-aware, the above example should tell you what to do.

Please, look at the shipped producers source code for example - code and look at the user guide on how to install and + code and look at the user guide on how to install and use your own producers.

-
+ -
+

If your servlet needs many parameters to work, it is more reasonable that you write a Processor instead. A Processor transforms a given XML document (which, in this case should contain the needed static parameters) @@ -158,55 +162,55 @@ it may have been produced from a file, from other sources or dynamically, see the above paragraph):

- - -

Current time is

- -]]> + +<?xml version="1.0"?> +<page> + <p>Current time is <time/></p> +</page> +

Our simple example processor will look for the %lg;time/%gt; tags and will expand them to the current local time, creating this result document:

- - -

Current time is 6:48PM

- -]]> + +<?xml version="1.0"?> +<page> + <p>Current time is 6:48PM</p> +</page> +

Please, look at the shipped processors source code for example - code and look at the user guide on how to install and + code and look at the user guide on how to install and use your own processors.

-
+ -
+

The above example shows a very simple situation but needs non-trivial code to implement it. For this reason, the Cocoon distribution includes a number of processors that implement common needs and situations. These are:

- - +
    +
  • The XSLT processor the XSLT processor that applies XSLT transformations to the input document. XSLT allows you to solve your transformation needs as well as simple tag evaluation/processing due to - its extensible and programmable nature. - + its extensible and programmable nature.
    • +
  • The DCP processor the DCP processor that evaluates XML processing instructions with multi-language (Java and EcmaScript) logic. This processor allows you to do programmatic substitution and inclusion - eliminating the need for complex processing logic. See the DCP - user guide for more information. - + eliminating the need for complex processing logic. See the DCP + user guide for more information.
    • +
  • The SQL processor the SQL processor that evaluates simple tags describing SQL queries to JDBC drivers and formats their result-set in XML - depending on given parameters. See the SQL - processor user guide for more information. + depending on given parameters. See the SQL + processor user guide for more information.
-
+ -
+

While the above represents a complete set of usable components for dynamic XML content generation, the Cocoon project aims to separate all three layers (content, logic and style). While XSLT transformations allow a @@ -214,9 +218,9 @@ separation between content and logic in dynamically generated XML pages is not achieved with current Cocoon features.

-

To fill this whole, the XSP - (eXtensible Server Pages) technology was proposed. While in the working +

To fill this whole, the XSP + (eXtensible Server Pages) technology was proposed. While in the working draft stage, we strongly believe that some of the issues expressed in that specification will be keys to the future of dynamic XML.

-
- + + \ No newline at end of file 1.2 +82 -98 xml-cocoon/docs/faq.xml Index: faq.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/faq.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- faq.xml 1999/11/20 01:16:22 1.1 +++ faq.xml 1999/11/30 16:29:51 1.2 @@ -1,127 +1,121 @@ - + -I don't find my question answered here, what do I do? - -

First, checkout the Java Apache FAQ-O-Matic - that contains a Cocoon section. You may find what you're looking for there. If - not, you may consult the mail - list digests and archives (we are aware of the problems regarding lack of - searching capabilities in the mail list archive and, yes, we are trying - to solve them). Then, if your problem is still unresolved, you should send a - message describing your problem with very detailed information about your - system, your status and your issues and asking for advice.

-

Please, keep in mind that nobody gets paid to answer your questions and be - respectful of the time others are investing to answer you. Also, please, - respect individual privacy and time by submitting help requests only to the - mail lists and not directly to developers or individuals.

-

At the end, if you come up with a solution for your problem, please, don't - throw away your effort, share it with us by directly adding it to the FAQ-O-Matic - and post it to the mail list. Thanks.

- + How do I pipe my servlet output into Cocoon? + +

Simple answer: you don't!!! read this + document instead to find out equivalent ways to do what you need.

+

Complex answer: the Servlet API was not designed with servlet + chaining capabilities in mind. Servlet chaining was a night hack of the + original Java web server authors that allowed to pipe one servlet output + into the request of another. Currently (version 2.2) the Servlet API spec + doesn't allow a servlet to post-process the output of another servlet, so, + since Cocoon is a servlet, there is no portable way for it to call + your servlet and to process its output.

+

The Cocoon Project is in close contact with the Servlet API Expert Group at + Sun (being Stefano Mazzocchi a member of that board) and will propose + post-processing hooks for inclusion in the next Servlet API specifications. + Since this is work in progress, please, don't fill up the mail list with + questions about this: Cocoon will reflect the API changes as soon as they + are publicly available.

+ + -How do I pipe my servlet output into Cocoon?

- -

- Simple answer: you don't!!! read this - instead to find out equivalent ways to do what you need.
-
- Complex answer: the Servlet API was not designed with servlet - chaining capabilities in mind. Servlet chaining was a night hack of the - original Java web server authors that allowed to pipe one servlet output - into the request of another. Currently (version 2.2) the Servlet API spec - doesn't allow a servlet to post-process the output of another servlet, so, - since Cocoon is a servlet, there is no portable way for it  to call - your servlet and  to process its output.
-
- The Cocoon Project is in close contact with the Servlet API Expert Group at - Sun (being Stefano Mazzocchi a member of that board) and will try to include - post-processing hooks in the next Servlet API specifications. Since this is - work in progress, please, don't fill up the mail list with questions about - this: Cocoon will reflect the API changes as soon as they are publicly - available.

- -Where do I get more information on XSL and XML? - + + "Where do I get more information on XSL and XML?" +

The web community is very exited about XML and XSL and many sources of information are coming up even if these languages are fairly new. Here is a list of locations you might be interested in to continue to gather resources on this state-of-the-art technology

 -The XSL book I found says the correct way of indicating the XSL stylesheet is by + + + + The XSL book I read says the correct way of indicating the XSL stylesheet is by using the XML processing instruction <?xml:stylesheet?> while Cocoon is - using <?xml-stylesheet?>. Who is right? - + using <?xml-stylesheet?>. Who is right? + +

The PI <?xml:stylesheet type="text/xsl" href=""?> is the old method of associating a stylesheet with an XML document. Unfortunately, this technology is rapidly changing and your books should warn you that the topic they are discussing is not even in W3C Recommendation state. Which means that more changes are on - their way.
-
- The current and proper way to associate a stylesheet with an XML document can be found at http://www.w3.org/TR/xml-stylesheet and + their way.

+

The current and proper way to associate a stylesheet with an XML document can be found at + http://www.w3.org/TR/xml-stylesheet and clearly indicates that <?xml-stylesheet ...?> is the proper way.

- -I think that using Processing Instructions to "chain" + + + + + + I think that using Processing Instructions to "chain" document layers somehow violates the context separation since I would like to be able to place style sensible information in sessions or request - parameters. What do you think about this? - + parameters. What do you think about this? + +

You are right, PI reaction breaks the context separation and it's, at the very end, the wrong approach. To follow a complete "model, view, controller" design pattern, one should be able to associate a different processing chain for each requested URI and for every possible request state - (with request parameters, session parameters and environment parameters).
-
- The proposed solution (as you read in the Cocoon2 - outline) is to have a regular expression based site map where site + (with request parameters, session parameters and environment parameters).

+

The proposed solution (as you read in the Cocoon2 + outline) is to have a regular expression based site map where site managers decide what processing chain to apply to each possible request. This somehow follows the mod_rewrite model in the Apache Web Server, but rather than URL rewriting, the site map allows site designers to control the behavior of their documents in one place without having to modify every - single reactive PI in each source file.
-
- So, you've been warned: the PIs will go away, current functionality will + single reactive PI in each source file.

+

So, you've been warned: the PIs will go away, current functionality will remain but the processing management will be abstracted one layer up.

 -What is WAP and I do I browse WML? + + + +What is WAP and I do I browse WML? -

- WAP stands for Wireless Application Protocol and WML stands for Wireless - Markup Language. For more information about these two, please refer to the WAP - Forum. For a client able to browse WML 1.1 look for the Nokia - WAP Toolkit.

+

WAP stands for Wireless Application Protocol and WML stands for Wireless + Markup Language. For more information about these two, please refer to the + WAP Forum. For a client able + to browse WML 1.1, Cocoon has been tested with the + Nokia WAP Toolkit which + emulates a Nokia WAP cell phone on your desktop.

 -When I compile Cocoon on my system, I get all a bunch of errors. What's wrong? + + + +When I compile Cocoon on my system, I get all a bunch of errors. What's wrong?

You probably didn't add all the needed packages to your compiler's classpath or used the wrong version of the servlet classes (Cocoon is @@ -137,33 +131,23 @@ only way to compile it is to manually indicate all the files to compile or to use the makefiles after removing the unwanted wrapper classes for the packages you don't have or you don't want.

- -

External XML entities don't get included in my documents. What's wrong?

- -

This is a well known bug in Cocoon. External entities don't work if not - used in an absolute URL format, so you should either use an http:// or file:// - URL with absolution location.

 -

My stylesheet doesn't sense the presence of my request parameters. How do -I pass them to it?

- -

 Another well known bug. Cocoon is not yet able to pass request - parameters to the stylesheets. It will be fixed in future releases.

- -Why the name "Cocoon"? - -

- (Cocoon's creator Stefano Mazzocchi answers): It's a pretty stupid reason and a funny + + + + Why the name "Cocoon"? + +

(Cocoon's creator Stefano Mazzocchi answers): It's a pretty stupid reason and a funny story: I spent my 1998 Xmas vacation with my girlfriend up on the Alps at her cottage. One - night, I couldn't sleep and I woke up to watch some TV and finishing reading the XSL + night I couldn't sleep, I went to watch some TV and finishing reading the XSL documentation I brought with me. Being a science fiction afficionado, I found out that Ron Howard's movie Cocoon was on and I started watching it. The idea of the XSL rendering servlet stoke me like the alien "cocoons" in the pool stroke those old men in the movie and, while watching, I started paper-coding it right away. After a while the movie was over and the publishing framework designed. The name "Cocoon" seemed right for the thing, meaning to be a way to bring new life to old ideas as well as to create cocoons - for such new ideas to become beautiful butterflies. :-)
-

+ for such new ideas to become beautiful butterflies. :-)

 + 1.2 +172 -223 xml-cocoon/docs/guide.xml Index: guide.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/guide.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- guide.xml 1999/11/20 01:16:25 1.1 +++ guide.xml 1999/11/30 16:29:51 1.2 @@ -1,22 +1,27 @@ - + - - - - + +
+ User Guide + + + +
-
+ + +

This document assumes the knowledge of the W3C recommendation or working drafts used in Cocoon (mainly XML, XSL in both its transformation and formatting capabilities). This document is not intended to be an XML or XSL tutorial but just shows how these technologies may be used inside the Cocoon framework to create web content.

-
+ -
+

Cocoon is a publishing system that allows you to separate web development in three different layers: content, style and logic.

@@ -35,24 +40,24 @@ loves me (they now treat me like I walk on water), and a couple of summer interns that I had helping me on the project are suddenly getting massively head-hunted by companies like AT&T now that they can put XML and XSL on -their resumes. In a word: Cocoon simply rocks! +their resumes. In a word: Cocoon simply rocks! -
+ -
+

Every good user guide starts with an Hello World example and since we hope to write good documentation (even if its hard like hell!), we start from there too. Here is a well-formed XML file that uses a custom and simple DTD

- - - Hello World! - - This is my first Cocoon page! - - -]]> + +<?xml version="1.0"?> +<page> + <title>Hello World!</title> + <content> + <paragraph>This is my first Cocoon page!</paragraph> + </content> +</page> +

Even if this page mimics HTML (in a sense, HTML was born as a simple DTD for homepages), it is helpful to note that there is no style information @@ -69,7 +74,7 @@ follow a W3C recommendation and add the XML processing instruction to map a stylesheet to a document:

- ]]> + <xml-stylesheet href"hello.xsl" type="text/xsl">

Now that our content layer is done, we need to create a stylesheet to convert it to a format readable by our web clients. Since most available web @@ -81,11 +86,11 @@ and define its own namespace accordingly to the W3C directions. So the skeleton of your stylesheet is:

- - - -]]> + +<?xml version="1.0"?> +<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"> +</xsl:stylesheet> +

Once the skeleton is done, you must include your template elements, which are the basic unit of operation for the XSLT language. Each template is @@ -98,18 +103,18 @@ root element. This must be transformed in all those tags that identify a good HTML page. Your template becomes:

- - - - <xsl:value-of select="title"/> - - - - - - -]]> + +<xsl:template match="page"> + <html> + <head> + <title><xsl:value-of select="title"/></title> + </head> + <body bgcolor="#ffffff"> + <xsl:apply-templates/> + </body> + </html> +</xsl:template> +

were some elements belong to the standard namespace (which we associate to HTML) and some others to the xsl: namespace. Here we find two of those @@ -122,39 +127,39 @@

Other possible templates are:

- -

- -

- - - -

- -

- -]]> + +<xsl:template match="title"> + <h1 align="center"> + <xsl:apply-templates/> + </h1> +</xsl:template> + +<xsl:template match="paragraph"> + <p align="center"> + <i><xsl:apply-templates/></i> + </p> +</xsl:template> +

After the XSLT processing, the original document is transformed to

- - - Hello - - -

Hello

-

- This is my first Cocoon page! -

- - -]]> + +<html> + <head> + <title>Hello</title> + </head> + <body bgcolor="#ffffff"> + <h1 align="center">Hello</h1> + <p align="center"> + <i>This is my first Cocoon page!</i> + </p> + </body> +</html> + -
+ -
+

When a document is processed by an XSLT processor, its output is exactly the same for every browser that requested the page. Sometimes it's very helpful to be able to discriminate the client capabilities and transform content layer into different views/formats. This is @@ -167,13 +172,13 @@ be applied. This is done by indicating in the stylesheet linking PI the media type, for example, continuing with the HelloWorld.xml document, these PIs

- - - + +<?xml version="1.0"?> +<?xml-stylesheet href="hello.xsl" type="text/xsl"?> +<?xml-stylesheet href="hello.text.xsl" type="text/xsl" media="lynx"?> ... -]]> +

would tell Cocoon to apply the hello.text.xsl stylesheet if the Lynx browser @@ -185,70 +190,70 @@ based on their User-Agent http header information. Cocoon is preconfigured to handle these browsers:

- - any Microsoft Internet Explorer, searches for MSIE (before - searching for Mozilla, since they include it too) - the Opera browser (before searching for Mozilla, since - they include it too) - the text-only Lynx browser - any Java code using standard URL classes - the Nokia WAP Toolkit browser - any Netscape Navigator, searches for Mozilla - +
    +
  • explorer any Microsoft Internet Explorer, searches for MSIE (before + searching for Mozilla, since they include it too)
    • +
  • opera the Opera browser (before searching for Mozilla, since + they include it too)
    • +
  • lynx the text-only Lynx browser
    • +
  • java any Java code using standard URL classes
    • +
  • wap the Nokia WAP Toolkit browser
    • +
  • netscape any Netscape Navigator, searches for Mozilla
    • +

but you can add your own by personalizing the cocoon.properties file modify the browser properties. For example

- browser.0=explorer=MSIE browser.1=opera=Opera browser.2=lynx=Lynx browser.3=java=Java browser.4=wap=Wapsody browser.5=netscape=Mozilla -]]> +

indicates that Cocoon should look for the token MSIE inside the User-Agent HTTP request header first, then Opera and so on, until Mozilla. If you want to recognize different generations of the same browser you should do find the specific string you should look for and indicate the order of searching since more browsers may contain the same string.

-
+ -
+

The Cocoon publishing system has an engine based on the reactor design pattern which is described in the picture below:

- +

Let's describe the components that appear on the schema:

- - wraps around the client's request and +
    +
  • Request wraps around the client's request and contains all the information needed by the processing engine. The request must indicate what client generated the request, what URI is being - requested and what producer should handle the request. - +
  • Producer handles the requested URI and produces an XML document. Since producers are pluggable, they work like subservlets for this framework, allowing users to define and implement their own producers. A producer is responsible of creating the XML document which is fed into the processing reactor. It's up to the producer implementation to - define the function that produces the document from the request object. - is responsible of evaluating what + define the function that produces the document from the request object.
    • +
  • Reactor is responsible of evaluating what processor should work on the document by reacting on XML processing instructions. The reactor pattern is different from a processing pipeline since it allows the processing path to the dynamically configurable and it increases performance since only those required processors are called to handle the document. The reactor is also responsible to forward the - document to the appropriate formatter. - transforms the memory representation of + document to the appropriate formatter.
    • +
  • Formatter transforms the memory representation of the XML document into a stream that may be interpreted by the requesting client. Depending on other processing instructions, the document leaves the reactor and gets formatted for its consumer. The output MIME type of - the generated document depends on the formatter implementation. - encapsulates the formatted document along - with its properties (such as length, MIME type, etc..) - is responsible of loading the formatted + the generated document depends on the formatter implementation.
    • +
  • Responseencapsulates the formatted document along + with its properties (such as length, MIME type, etc..)
    • +
  • Loader is responsible of loading the formatted document when this is executable code. This part is used for compiled server pages where the separation of content and logic is merged and compiled into a Producer. When the formatter output is executable code, it @@ -256,21 +261,21 @@ as a document producer. This guarantees both performance improvement (since the producer are cached) as well as easier producer development, following the common compiled server pages model. [this part is not yet - implemented] - -
+ implemented] + + -
+

The Cocoon reactor uses XML processing instructions to forward the document to the right processor or formatter. These processing instructions are:

- for processing + +<?cocoon-process type="xxx"?> for processing and - for formatting -]]> +<?cocoon-format type="yyy"?> for formatting +

These PIs are used to indicate the processing and formatting path that the document should follow to be served. In the example above, we didn't use them @@ -278,17 +283,17 @@ document should be processed by the XSLT processor. To do this, the HelloWorld.xml document should be modified like this:

- - - - - Hello World! - - This is my first Cocoon page! - - -]]> + +<?xml version="1.0"?> +<?cocoon-process type="xslt"?> +<?xml-stylesheet href="hello.xsl" type="text/xsl"?> +<page> + <title>Hello World!</title> + <content> + <paragraph>This is my first Cocoon page!</paragraph> + </content> +</page> +

The other processing instruction is used to indicate what formatter should be used to transform the document tree into a suitable form for the requesting @@ -296,84 +301,32 @@ DTD, the Cocoon PI indicates that this document should be formatted using the formatter associated to the text/xslfo document type.

- - - - - - - - - - - - - - - - - Welcome to Cocoon - - - -]]> + +<?xml version="1.0"?> +<?cocoon-format type="text/xslfo"?> + +<fo:root xmlns:fo="http://www.w3.org/XSL/Format/1.0"> + <fo:layout-master-set> + <fo:simple-page-master page-master-name="one" margin-left="100pt" margin-right="100pt"> + <fo:region-body margin-top="50pt" margin-bottom="50pt"/> + </fo:simple-page-master> + </fo:layout-master-set> -

Cocoon comes with a number of processors and formatters which are - configured as follows

- - - - type - class - - - - Processors - xslt - org.apache.cocoon.processor.xslt.XSLPProcessor - The XSLT Processor - - - dcp - org.apache.cocoon.processor.dcp.DCPProcessor - The DCP Processor - - - sql - org.apache.cocoon.processor.sql.SQLProcessor - The SQL Processor - - - Formatters - text/xml - org.apache.cocoon.formatter.xml.OpenXMLXMLFormatter - General XML Formatter - - - text/html - org.apache.cocoon.formatter.html.OpenXMLHTMLFormatter - HTML 4.0 Formatter - - - text/xhtml - org.apache.cocoon.formatter.xhtml.OpenXMLXHTMLFormatter - XHTML Formatter - - - text/wml - org.apache.cocoon.formatter.wml.OpenXMLWMLFormatter - WML 1.1 Formatter - - - text/xslfo - org.apache.cocoon.formatter.pdf.FOPFormatter - PDF Formatter - -
-
+ <fo:page-sequence> + <fo:sequence-specification> + <fo:sequence-specifier-repeating page-master-first="one" page-master-repeating="one"/> + </fo:sequence-specification> + + <fo:flow font-size="14pt" line-height="14pt"> + <fo:block>Welcome to Cocoon</fo:block> + </fo:flow> + </fo:page-sequence> +</fo:root> + + + -
+

In a complex server environment like Cocoon, performance and memory usage are critical issues. Moreover, the processing requirement for both XML parsing, XSLT transformations, document processing and formatting are @@ -383,34 +336,29 @@

Its operation is simple but rather powerful:

- - when the request comes, the cache is searched. - - if the request is found; - - its changeable points are evaluated - if all changeable points are unchanged - - the page is served directly from the cache - - - if a single point has changed and requires reprocessing - - the page is invalidated and continues as if it wasn't found - - - - - if the request is not found: - - the page is normally processed - it's sent to the client - it's stored into the cache - - - - - +
    +
  • when the request comes, the cache is searched.
    • +
      +
    • if the request is found;
      • +
        +
      • its changeable points are evaluated
        • +
      • if all changeable points are unchanged
        • +
          +
        • the page is served directly from the cache
          • +
        +
      • if a single point has changed and requires reprocessing
        • +
          +
        • the page is invalidated and continues as if it wasn't found
          • +
        +
      +
    • if the request is not found:
      • +
        +
      • the page is normally processed
        • +
      • it's sent to the client
        • +
      • it's stored into the cache
        • +
      +
    +

This special cache system is required since the page is processed with the help of many components which, independently, may change @@ -436,5 +384,6 @@ processors which store their stylesheets in a pre-parsed form to speed up execution in those cases where the original file has changed, but the stylesheet has not (which is a rather frequent case).

-
- + + + \ No newline at end of file 1.2 +44 -35 xml-cocoon/docs/index.xml Index: index.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 1999/11/20 01:16:26 1.1 +++ index.xml 1999/11/30 16:29:51 1.2 @@ -1,13 +1,20 @@ - + - - - - + -
+ +
+ Cocoon + XML Publishing Framework + + + +
+ + +

Cocoon is a 100% pure Java publishing framework that relies on new W3C technologies (such as DOM, XML, and XSL) to provide web content. @@ -26,9 +33,9 @@ Read the Introduction on Cocoon technologies white paper to find out more on the subject.

-
+ -
+

Web content generation is mostly based on HTML, but HTML doesn't separate the information from its presentation, mixing formatting tags, descriptive tags and @@ -36,9 +43,9 @@ allowing content, logic and style on different XML files and uses XSL transformation capabilities to merge them.

-
+ -
+

Even if the most common use of Cocoon is the automatic creation of HTML through the processing of statically or dynamically generated XML files, Cocoon is also @@ -60,26 +67,26 @@

To do this, the Cocoon model divides the development of web content in three separate levels: - - - the XML file is created by the content owners. They do not +

+ +
+
XML creation
+
the XML file is created by the content owners. They do not require specific knowledge on how the XML content is further processed rather than the particular chosen DTD/namespace. This layer is always performed by humans directly - through normal text editors or XML-aware tools/editors. - - - the requested XML file is processed and the logic contained in its + through normal text editors or XML-aware tools/editors.
+
XML processing
+
the requested XML file is processed and the logic contained in its logicsheet is applied. Unlike other dynamic content generators, the logic - is separated from the content file. - - the created document is then rendered by applying an XSL - stylesheet to it and formatting it to the specified resource type (HTML, PDF, XML, WML, XHTML) - - -

-
+ is separated from the content file. +
XSL rendering
+
the created document is then rendered by applying an XSL + stylesheet to it and formatting it to the specified resource type + (HTML, PDF, XML, WML, XHTML)
+ + -
+

The biggest known problem in this framework is the lack of XML/XSL knowledge, being relatively new formats. We do believe, though, that this publishing @@ -112,7 +119,7 @@ sites. In fact, the Cocoon projects aims to gather as much information as possible during it's first generation while its second generation, starting from Cocoon 2.0, will aim to be a usable and real-life publishing framework. - See the Cocoon 2 outline to understand the + See the Cocoon 2 outline to understand the design plans already established.

@@ -122,16 +129,16 @@ web browsers since the XSL rendering would be then performed on client side reducing the server work.

-
+ -
+

- Go to the download area + Go to the download area and be sure you read the release note in that page.

-
+ -
+

The Cocoon Project is an open volunteer project based on the spirit of the Apache Software Foundation (ASF). @@ -147,7 +154,7 @@ (follow the link for information on how to subscribe and to access the mail list archives), to checkout the latest and greatest code (which you found in the xml-cocoon module in - the xml.apache.org CVS code repository), control the todo + the xml.apache.org CVS code repository), control the todo list and jump in. Document writers are usually the most wanted people so if you like to help but you're not familiar with technical details, don't worry we have work for you. @@ -172,5 +179,7 @@

Thank you very much.

-
- + + + + 1.2 +51 -48 xml-cocoon/docs/installing.xml Index: installing.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/installing.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- installing.xml 1999/11/20 01:16:28 1.1 +++ installing.xml 1999/11/30 16:29:51 1.2 @@ -1,36 +1,39 @@ - + - + - - - - - + +
+ Installing Cocoon + + + +
-
+ +

Cocoon requires the following systems to be already installed in your system:

- - +
    +
  • Java Virtual Machine A Java 1.1 or greater compatible virtual machine must be present for both command line and servlet type usage of Cocoon. Note that all servlet engines require a JVM to run so if you are already using servlets you already have one installed. - - +
    • +
  • Servlet Engine A Servlet 2.x compliant servlet engine must be present in order to support servlet operation and dynamic request handling. Note that this requirement is optional for command line operation. - - +
    • +
-
+ -
+

Cocoon is a publishing framework and was designed to be highly modular to allow users to choose their preferred implementation for the required @@ -61,9 +64,9 @@ engine.

-
+ -
+

Being Cocoon a servlet, you should be able to install it on every compliant servlet engine by associating the "org.apache.cocoon.Cocoon" servlet @@ -72,7 +75,7 @@ servlet systems.

-
+

Apache JServ has one configuration file for the whole engine (normally called jserv.properties) and one for each servlet zone. Please, refer @@ -146,50 +149,51 @@ where .xml is the file extention you want to map to the servlet and /servlet/ is the mount point of your servlet zone (and the above is the standard name for servlet mapping for Apache JServ). -

> +

Everything should be configured fine. Restart both Apache and Apache JServ and try accessing the samples contained in the distribution to see Cocoon in action.

-
+ -
+

Yet to be written! Volunteers welcome!

-
+ -
+

Yet to be written! Volunteers welcome!

-
+ -
+

Yet to be written! Volunteers welcome!

-
+ -
+ -
+

Cocoon has been reported to be working on these systems:

- - RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.8 - RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.8 - RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + Blackdown JDK 1.2pre2 - RedHat Linux 6.1 + Apache 1.3.9 + JRun 2.3.3 + IBM JRE 1.1.8 - Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.7 - Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.7 - Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + Sun JDK 1.2.2 - Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.2.2 - Windows 98 + MS Personal Web Server + ServletExec 2.2 + Sun JDK 1.2.1 - Windows NT 4.0 + IIS 4.0 + ServletExec 2.2 + Sun JDK 1.2.1 - Windows NT 4.0 + IIS 4.0 + JRun 2.3.3 + Sun JDK 1.2.1 - MacOS 8.6 + WebSTAR 4.0 + JRun 2.3 + MrJ 2.1.4 - MacOS 8.6 + WebSTAR 4.0 + ServletExec 2.1 + Mrj 2.1.4 - SunOS Netria 5.6 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.1.7 - +
    +
  • RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.8
    • +
  • RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.8
    • +
  • RedHat Linux 6.0 + Apache 1.3.9 + Apache JServ 1.0 + Blackdown JDK 1.2pre2
    • +
  • RedHat Linux 6.1 + Apache 1.3.9 + JRun 2.3.3 + IBM JRE 1.1.8
    • +
  • Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + IBM JDK 1.1.7
    • +
  • Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + IBM JDK 1.1.7
    • +
  • Windows 98 + Apache 1.3.9 + Apache JServ 1.0 + Sun JDK 1.2.2
    • +
  • Windows 98 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.2.2
    • +
  • Windows 98 + MS Personal Web Server + ServletExec 2.2 + Sun JDK 1.2.1
    • +
  • Windows NT 4.0 + IIS 4.0 + ServletExec 2.2 + Sun JDK 1.2.1
    • +
  • Windows NT 4.0 + IIS 4.0 + JRun 2.3.3 + Sun JDK 1.2.1
    • +
  • MacOS 8.6 + WebSTAR 4.0 + JRun 2.3 + MrJ 2.1.4
    • +
  • MacOS 8.6 + WebSTAR 4.0 + ServletExec 2.1 + Mrj 2.1.4
    • +
  • SunOS Netria 5.6 + Apache 1.3.9 + Apache JServ 1.1b3 + Sun JDK 1.1.7
    • +
  • SCO OpenServer 5 + WebLogic 4.5.1 + SCO JDK 1.1.7A
    • +

Note: due to a bug in Blackdown @@ -201,6 +205,5 @@ Please, submit your feedback if you were able to install Cocoon on a different combination not listed above. Thanks.

-
- - + + \ No newline at end of file 1.2 +13 -9 xml-cocoon/docs/license.xml Index: license.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/license.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- license.xml 1999/11/20 01:16:29 1.1 +++ license.xml 1999/11/30 16:29:51 1.2 @@ -1,14 +1,17 @@ - + - + +
+ Cocoon Public License + + + +
- - - - -
+ + . ]]> -
- \ No newline at end of file + + + \ No newline at end of file 1.2 +14 -9 xml-cocoon/docs/sqlprocessor.xml Index: sqlprocessor.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/sqlprocessor.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- sqlprocessor.xml 1999/11/20 01:16:32 1.1 +++ sqlprocessor.xml 1999/11/30 16:29:51 1.2 @@ -1,13 +1,18 @@ - + - - - - + +
+ SQLProcessor User Guide + + + +
-
-

Yet to be XML-ized!

-
- \ No newline at end of file + + +

Yet to be XML-ized!

+ + + \ No newline at end of file 1.2 +104 -100 xml-cocoon/docs/technologies.xml Index: technologies.xml =================================================================== RCS file: /home/cvs/xml-cocoon/docs/technologies.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- technologies.xml 1999/11/20 01:16:40 1.1 +++ technologies.xml 1999/11/30 16:29:51 1.2 @@ -1,24 +1,28 @@ - + - - + +
+ Introduction on Cocoon Technologies - - + + +
-
+ + +

Many people do not seem to understand the global picture about the technologies used by Cocoon, I will try to explain my vision of these technologies as well as some information that might be useful to you to jump in, help with its development or show your boss how much money he can save.

-
+ -
+

XML (eXtended Markup Language) is an SGML subset. SGML is the father of all markup languages and its a 15-years old ISO standard for creating languages. @@ -28,8 +32,8 @@ Exactly like ASCII that defines a standard way to map characters to bytes and not a bunch of character strings.

-

XML is usually referred to as "portable data" in the sense that its -parsing is "application independent" and one XML parser can read every +

XML is usually referred to as portable data in the sense that its +parsing is application independent and one XML parser can read every possible XML document, one describing your bank account, another describing your favorite Italian meal, etc. This is, as you all know, impossible with other file formats which are text based or binary. Some sort of equivalent in the old days @@ -41,15 +45,15 @@

A particular XML language is defined by its Document Type Definition (DTD) which is described inside the XML specification. An XML document may be validated against a DTD (if present) and if the validation is successful the -document is said "valid XML based on the particular DTD", if a DTD is +document is said valid XML based on the particular DTD, if a DTD is not present and the parser does not encounter syntax errors parsing the file, -the XML document is said "well-formed". If errors are found, the +the XML document is said well-formed. If errors are found, the document is not XML compliant.

So, any valid XML document is well-formed and an XML document valid for one particular DTD may not necessary be valid for another DTD. -For example, HTML is not an XML language because the <br> tag -is not XML compliant. XHTML (where <br> is replaced by <br/>) +For example, HTML is not an XML language because the <br>> tag +is not XML compliant. XHTML (where <br>> is replaced by <br/>>) is XML compliant. While HTML pages are not always XML documents (some pages might be), XHTML pages are always well-formed and valid if matched against the XHTML DTD.

@@ -57,34 +61,34 @@

So far for the technical differences, but why HTML was not good enough? Let's make an example.

-
+ -
+

Consider why the need for XML came about:

- - Everyone starts pubitemshing HTML documents on the web. - Search engines spring up across the net to help find documents. - Search engines have a difficult time searching specific pieces of a +
    +
  • Everyone starts pubitemshing HTML documents on the web.
    • +
  • Search engines spring up across the net to help find documents.
    • +
  • Search engines have a difficult time searching specific pieces of a document since HTML was designed to hierarchically represent how data - should be presented, but not what the data being presented is. - Web appitemcations spring up across the net to provide information and - "services". - + should be presented, but not what the data being presented is.
    • +
  • Web appitemcations spring up across the net to provide information and + services.
    • +

These services could be web pages that serve up important information about an organization or the structure of the organization. They could be weather information, or travel advisories. They could be contact information for people. Stock quotes. It could a book on how to grow the perfect Tomato.

So now we have all this information. Tons of it. Great! Now go and search all these web pages for specific content, like Author or Subject. Find me all - abstracts of any documents published that have a subject of "Big Tomatoes", + abstracts of any documents published that have a subject of Big Tomatoes, since I only want to view abstracts to find out which document is best for me. An HTML page is not designed for this. It was designed for how to present the data.

When I look at a web page I might see that an author choose to make every - paragraph heading bold with <font size+1>. Yet if I look at - another page I might notice that every paragraph heading was marked up with <H1>. + paragraph heading bold with <font size+1>>. Yet if I look at + another page I might notice that every paragraph heading was marked up with <H1>>. Yet another page may use tables and table headers to format the data. Find me - every document that has the word "potato" in the paragraph heading + every document that has the word potato in the paragraph heading of the first paragraph.

Suppose I have a weather web-based application that servers up weather information for different parts of the country. Let's say you live in Boston, @@ -112,74 +116,74 @@ weather information. And another link that says XML stream for weather information available. Yikes, would you look at that:

- - - Boston - MA - - + + <weather-information> + <location> + <city>Boston</city> + <state>MA</state> + </location> + <summary> Beautiful and Sunny, lows 50, highs 65, with the chance of a blizzard and gail force winds. - - - ]]> + </summary> + </weather-information> +

So you download Cocoon, simply write an XSL stylesheet that looks the the following:

- - + + <xsl:stylesheet> + <xsl:template match="/"> ... presentation info here ... - - - - - - ]]> + </xsl:template> + <xsl:tempate match="weather-information[location/city = 'Boston']"> + <xsl:apply-templates select="summary"/> + </xsl:template> + </xsl:stylesheet> +

And your boss gives you your job back! ;-)

-
+ -
+

As the above example explains very well, HTML is a language for describing graphics, behavior and hyperlinks on web pages. HTML is NOT able to contextualize -(means "give meaning to some text") in the sense that if you look for -the "title" of your page, a nice HTML tag gives you that, but if you +(means give meaning to some text) in the sense that if you look for +the title of your page, a nice HTML tag gives you that, but if you look at the author or version or something more specific like the author mail address, even if this information is present in the text you don't have a way to -"isolate" this (contextualize it) from the surrounding information.

+isolate this (contextualize it) from the surrounding information.

In some HTML like this

- - - This is my article - - -

This is my article

-

Stefano Mazzocchi

+ + <html> + <head> + <title>This is my article</title> + </head> + <body> + <h1 align="center">This is my article</h1> + <h3 align="center>by <a href="mailto:stefano@apache.org">Stefano Mazzocchi</a></h3> ... - - -]]> + </body> + </html> +

you don't have a guaranteed way to extract the mail address, while in the following XML document

- - - This is my article - - Stefano Mazzocchi - stefano@apache.org - + + <?xml version="1.0"?> + <page> + <title>This is my article</title> + <author> + <name>Stefano Mazzocchi</name> + <mail>stefano@apache.org</mail> + </author> ... - -]]> + </page> +

it's trivial and algorithmically certain.

@@ -189,9 +193,9 @@ complex dynamic information systems, but only to parallelize and simplify the deployment and management of personal information.

-
+ -
+

As you see, XML alone is useless without some defined semantics: even if an application is able to parse a document in memory, it must be able to understand @@ -204,17 +208,17 @@ XML DTDs that define a particular XML syntax. So every XSL and XSLT document is a well-formed XML document.

-
+ -
+

XSLT is a language for transforming one well-formed XML document into something else. This means that you may use it to go from one DTD to another in an procedural way that is defined inside your XSLT document. Even if the name tells the opposite, this language can be used for document styling as well as for many other useful transformations: in fact, transformations may be applied to one particular XML -DTD and come up with some "graphical description" of the original -content. This is called "styling", but, as you can see, this is just +DTD and come up with some graphical description of the original +content. This is called styling, but, as you can see, this is just one of the possible uses of the technology.

For example, the above HTML example may be created from the second XML file @@ -227,47 +231,47 @@ reason may be used in chain: transformA goes from DTD1 to DTD2 and transformB from DTD2 to DTD3 or graphically

-DTD1 ---(transformA)--> DTD2 ---(transformB)---> DTD3 +DTD1 ---(transformA)-->> DTD2 ---(transformB)--->> DTD3

We'll call DTD1 the original DTD (because its the origin), DTD2 some intermediate DTD, DTD3 the final DTD. It can be shown that a transformation can always be created to go directly from DTD1 to DTD3, but this might be more complicated and less human readable/manageable.

-
+ -
+

XSLFO is a language (an XML DTD) for describing 2D graphics of text in both printed and digital media. I will not concentrate on the graphical abilities that formatting objects gives you, but rather on the fact that it is most of the -time used as a "final DTD", meaning that a transformation is used to +time used as a final DTD, meaning that a transformation is used to generate a formatting object description of a document starting from a general XML file.

The example above would lead:

- - + + <?xml version="1.0"?> + <fo:root xmlns:fo="http://www.w3.org/XSL/Format/1.0"> ... - - This is my article - by Stefano Mazzocchi - - -]]> + <fo:flow font-size="14pt" line-height="14pt"> + <fo:block text-align="centered" font-size="24pt" line-height="28pt">This is my article</fo:block> + <fo:block space-before.optimum="12pt" text-align="centered">by Stefano Mazzocchi</fo:block> + </fo:flow> + </fo:root> +

which tells the formatting object formatter (the rendering engine), how to - "draw" and place the text on the screen or on paper. Formatting + draw and place the text on the screen or on paper. Formatting objects and transformations are created by the same working group and show very high synergies even if the XSLT specification also includes way to create HTML and text out of XML files as well.

-
+ -
+

The Cocoon publishing model is heavily based on the XSLT transformation capabilities that allow complete separation of content and style (something @@ -278,8 +282,8 @@

The XSP language (eXtensible Server Pages) languages defines an XML DTD for separating content and logic for compiled server pages. - XSP (eXtensible Server Pages) is, like XSLFO, supposed to be a "final - DTD" in the sense that is the result of one or more transformation steps + XSP (eXtensible Server Pages) is, like XSLFO, supposed to be a final + DTD in the sense that is the result of one or more transformation steps and must be rendered by some formatter into pure source code that can then be compiled into binary code.

@@ -297,7 +301,7 @@ pure content to these final DTDs, placing the style and logic on the transformation layers and guaranteeing complete separation and easier maintenance.

- -
- + + + \ No newline at end of file 1.1 xml-cocoon/docs/WD-xsp.xml Index: WD-xsp.xml ===================================================================
eXtensible Server Pages (XSP) Layer 1 11091999 Working Draft This is an Apache Working Draft for review by all interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Working Drafts as reference material or to cite them as other than "work in progress". This work is part of the Apache Cocoon Project This document specifies an XML namespace that addresses a complete region of web publishing, that of logic-based, dynamic content generation. This language is introduced to fill an existing gap between the W3C specifications and working draft and the increasing demand for a flexible server side approach based on the new XML paradigm.

This document specifies both an XML document type definition and a development methodology to generate dynamic XML by server side processing of client's requests. Such a specification is useful to define an open and standard way to develop and maintain dynamic XML server pages. The technology described in this document was designed to complete the XML-based publishing framework defined by the Cocoon Project and it's mainly targeted on this project, even if the final goal of this effort is to submit a request to a standard body (such as W3C) for final recommendation.

The need for an open language to standardizing server side programmatic XML generation was observed when XML-based web publishing frameworks emerged and no available technology was detailed, stable, useful and open enough to be used. XSP, by mixing Turing-complete programming logic with page content, provide a flexible yet fully portable and extensible way to develop dynamic XML content. Moreover, being completely XML-based, XSP are fully integrated with XML-based web architectures that allow XSL-transformation to obtain the context separation that is needed for complex sites to increase their management parallelism.

Being based on an XML paradigm from the beginning, XSP don't suffer limitations other server pages technologies do: the ability to XSL-transform XSP directly and recursively allows a more compact and precise DTD to be designed since content/logic/style separation is performed by the architecture and not by the language itself. For this reason, XSP are completely transparent to the namespaces/document-types used.

Being a rather complex technology, the XSP specification will be separated into layers. These layers will have different goals and restrictions and will allow faster development cycles and a better defined development model. Every layer will define its own document type definition which may extend the one of the previous layer or completely change it, depending on layer goals. Layers should be seen as levels of abstraction, much like programming languages range from higher-levels to lower-levels.

Following is a summary of the design principles governing the general XSP specification:

  1. should integrate completely with existing W3C recommendations and working drafts
  2. should be programming language independent
  3. should be aimed to programmers but should be relatively easy to understand
  4. should allow pages to be compiled (into Java servlets or other equivalent technology)
  5. should not aim to replace existing technologies
  6. should be document oriented
  7. should allow easy reusability of page code
  8. should allow complete separation of knowledge contexts (content, logic and style)
  9. should be transparent to all but page programmers
  10. specification should be open to all but controlled directly by the Cocoon Project

Following is a summary of the design principles governing the Layer 1 of the XSP specification:

  1. should define the complete element set
  2. should be aimed to machine generations so:
    • reducing the number of elements to a minimum is of maximal importance
    • verbosity of the generated documents is of minimal importance
  3. should be human readable/editable so:
    • terseness and readability are of maximal importance
    • indenting and formattation are of maximal importance
  4. should be possibly XSLT transformed directly into programming language source code
  5. should define the relations to the programming languages (object models, variable scopes)

Following is a summary of the design principles governing the Layer 2 of the XSP specification:

  1. should define a human oriented element set
  2. should be aimed to human generations so:
    • reducing the number of elements to a minimum is of minimal importance
    • reducing verbosity of the documents is of maximal importance
  3. should be aimed to medium-low knowledged programmers:
    • automatization of complex operations is of maximal importance
    • tendency to hide page logic is of maximal importance
  4. should be possibly XSLT transformed into XSP Layer 1 documents

The XSP specification would eventually evolve into a single specification with a single document type definition. This will happen when the working draft phase will be terminated and all involved parties will agree on the specification stability. The Layer 1 will be the first to be developed and tested in a working implementation. Subsequent layers will probably need several evolution stages to reach their final shape.

Three standards have been especially influential:

  • JSP defines a way to embed programmatic logic into web documents.
  • XSLT defines a way to transform XML documents.
  • XML defines a flexible still highly structured paradigm for web content generation and distribution.

Many server side dynamic web content generators have been evaluated and confronted, especially WebMacro and GSP.

The following basic terms apply in this document:

document
a document is the final result of the client request phase and they can be obtain from a single file that is read from disk/cache or by processing several ones. Documents are said static if their content doesn't change with user request parameters nor time. Documents are said dynamic if they do.
page
a page is the entity that is requested by the client and drives the document creation process. In the simplest case, a document is created reading the page and sending it directly without further processing. In case of compiled pages, a binary object is executed and it's content is used as page content. Pages are said compiled if they are translated into binary code. Note that compiled pages may be created from normal pages the first time the page is requested and executed as binary code in further requests for performance reasons.
sheet
a sheet is the processing unit of the document creation chain. Each sheet is a file and they contain the instructions to transform the requested page into the document sent to the requesting client. Sheets are said style sheets if they are the last of the chain and no further processing in performed, logic sheets if they contain XSP elements. Both types are said transformation sheets since they contain XSLT elements.
document type
a document type is a unique name that identifies the type of the document being generated. This term has the same meaning as in the XML specification. Note how a document has only one document type but this could change during processing since transformation sheets allow the transformation from one document type into another.

The XSP specification defines some external entities that may be used to reduce the verbosity of XSP document, allowing the inclusion the default DTD via entity mapping. The standard way to include the XSP DTD into XSP documents is:

The XSP DTD was designed with simplicity in mind. The number of elements and attributes was reduced to a minimum to allow a fast and easy learning process. On the other hand, no special helper elements were defined in Layer 1 to reduce the spec development time and to favor early feedback from both implementers and users.

The following is the complete DTD. It must be noted that this DTD can hardly be used (alone) to validate any XSP due to the fact that XSP are namespace orthogonal and are designed to include as content mark-up elements that belong to other namespaces. The XSchema effort will allow multi-namespace validation.

Consider the following XML source document:

This simple example shows the power of content/logic/style separation. While the <title> tag has a very special meaning in the page document type, indicating the page title, the <counter> element is needs to be dynamically substituted by the number of times the document has been requested. The logic that performs such behavior is included in tag itself, but unlike other existing server side technologies, the behavior is not defined in the page itself, but on the logic sheet that is applied to evaluate this behavior. In fact, the same page may have a totally different behavior depending on the logicsheet that is applied to the page. Note that it's beyond the scope of this specification to define a way to associate transformation sheets to pages. The associated logicsheet that uses the Java language as logic definition may look like:

After applying the above logic sheet, the resulting document would be equivalent to the following:

Note that in this example the XML document is being generated as a stream but a DOM tree is used to create it. The DOM tree can't be passed directly to the servlet engine for further processing because the current servlet specification (2.2) does not allow for content generation in a format other than a stream. A rather undesirable consequence of this is that the resulting XML document would need to be re-parsed in case a final XSL stylesheet or other post-transformation must be applied.

To solve this problem and speed up the execution on server side XML processing, the XSP can be compiled into something like this:

The above shows one of the best features of XSP: output independence. Since the output objects are not accessible directly from the internal page logic (unlike other similar technologies, such as JSP), the page compiler can choose between a great variety of possible ways to generate and forward the page content. In fact, while the first example uses DOM as a construction set and a stream as output method, the exact same page is compiled in the second example to use a SAX event-based model and a document handler as output.

Finally, It is beyond the scope of this specification to define how XSP are translated into binary code and how these interact with the publishing frameworks that handle them, but it is mandated that this should be completely transparent to the page programmer and an XSP page should behave exactly the same (modulo performance) in every XSP engine.

XSP and JSP might appear as overlapping at a first glance since they both:

  • follow the compiled server pages model, allowing server pages to be compiled into binary code for faster execution.
  • can be parsed and validated by regular XML parsers
  • can be transformed by XSLT processors
  • aim to programming language abstraction

While these are very important points were the two specifications do overlap, there are significant differences described hereafter.

In all different server pages technologies, some data regarding the status of the resource are available to page logic. Since JSP follow the Servlet API model, expecting JSP pages to be compiled into servlets, the same data available to servlet is available to page logic. This allows the page logic to obtain access to the output channel (being either an OutputStream or a Writer for servlets).

While this is not a problem for normal web operation when no further server side processing is performed, for XML generation (where further server side processing may be needed, depending on client capabilities) the Servlet/JSP limitations impose on the server pages engine a parsing stage that is completely avoided in XSP.

In fact, in XSP, page logic has not direct access to the output channel and it's the page compiler responsibility to choose the preferred method to compile the page, depending on processing needs and server requirements.

It should be noted how XSP spec provides three different contexts: content, logic and eval. These three contexts never overlap since content is used to create static markup content, logic to indicate programming logic and eval to bridge the two domains, allowing a logic component to be evaluated without exposing the output channel to the logic context.

This is a very significant difference since it allows XSP page compiler to hardcode pre-parsed XML content thus removing the request time parsing overhead that JSP always require.

For these reasons, XSP, unlike JSP, uses the XML feature of syntax orthogonalily that allows almost any programming language code to be easily distinguishable between markup elements, while JSP needs to enclose programming code by scriptlet tags. The following is an example to show the different results based on the same logic and code.

This is the JSP equivalent:

It must be noted the use of the out object in the JSP example while XSP provide specific tags to avoid that.

The following people have greatly contributed to the creation and design of this draft:

  • Ricardo Rocha <rrocha@plenix.org>

Copyright (c) 1999 Apache XML Project. All Rights Reserved.
1.1 xml-cocoon/docs/javadoc.xml Index: javadoc.xml ===================================================================
Javadoc Documentation in XML

We are currently working on enhancing the documentation provided for the Cocoon XML publishing framework by converting javadoc commented source code into XML for use within Cocoon.

In order to do this we are currently planning to implement the following phases:

  1. Develop a JavaDoc XML DTD that acts as a data structure representing the information provided by the rootDoc object of the SUN Javadoc program to a plugged doclet. This DTD is intended to closely mirror the look of a raw java source file.
  2. Develop a JavaDoc doclet (JavaDocXML) that takes the information from the JavaDoc rootDoc object and converts it into an XML file using the javadoc.dtd.
  3. Wrap the javadoc with XML doclet invocation into a cocoon producer as follows:
    • reads the document from the file system
    • spawns the javadoc tool using the javadoc XML servlet and using the parameters found in the "javadoc makefile"
    • produces the XML output as a single document
    • the Cocoon engine process it with the stylesheet indicated (from command line or whatever)
    • formats it either as PDF or HTML or whatever depending on the chosen stylesheet. (the HTML formatter will be able to split a single XML document into several ones based on special page-break tags or PIs or using FO directly)
    • formatter will also be able to react on the SVG namespace inlining vector graphics or formatted as raster graphics.
  4. Some final formats we could produce are:
    • javadoc.dtd ---> javadoc_html.dtd ---> HTML (this would create a javadoc that looks like the current HTML javadoc standard).
    • javadoc.dtd ---> docBook.dtd  (this would facilitate printed books based having heavy content about java API's. For example "The JDBC API Tutorial and Reference: 2nd Edition" could make heavy use of this.
    • javadoc.dtd ---> ebook.dtd (this would facilitate the electronic version of documentation)
    • javadoc.dtd ---> ??? ---> pdf 
  5. Using this method we will then enhance the existing Cocoon documentation to provide rich documentation using some subset of the above formats.
  6. Finally, we can incorporate XML versions of UML vector diagrams to further enhance the source code documentation.

Current Status: Phase 2

Items currently under development:

  • Phase 1
    • javadoc.dtd
      • Note: I still need to update the sample to reflect the use of namespaces and the addition of the interfaceref element
  • Phase 2
    • Working on XML javadoc doclet

Currently, I am needing lots of feedback on the javadoc.dtd. We can't proceed to phase 2 until we feel we are on the right track with the DTD. It doesn't need to be perfect, but it should be close. When I get the next round of feedback, I am planning on adding "import" as an element of class. I am also planning on moving the position of the element "doc" to the start of each place it is appropriate. They will more closely reflect the source code and it just makes since to put the documentation before not after what you are talking about.

 1.1 xml-cocoon/dtd/changes-v10.dtd Index: changes-v10.dtd =================================================================== %document-dtd; 1.1 xml-cocoon/dtd/characters.ent Index: characters.ent =================================================================== 1.1 xml-cocoon/dtd/document-v10.dtd Index: document-v10.dtd =================================================================== %charEntity;