Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 69917 invoked by uid 500); 8 Jan 2003 08:40:33 -0000 Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: forrest-dev@xml.apache.org Delivered-To: mailing list forrest-dev@xml.apache.org Received: (qmail 69885 invoked from network); 8 Jan 2003 08:40:32 -0000 Received: from cocoondev.org (209.15.201.32) by daedalus.apache.org with SMTP; 8 Jan 2003 08:40:32 -0000 Received: (qmail 24633 invoked from network); 8 Jan 2003 08:40:44 -0000 Received: from otsrv1.iic.rug.ac.be (HELO outerthought.org) (157.193.121.51) by cocoondev.org with SMTP; 8 Jan 2003 08:40:44 -0000 Message-ID: <3E1BE409.1020004@outerthought.org> Date: Wed, 08 Jan 2003 09:40:41 +0100 From: Marc Portier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en, nl-be MIME-Version: 1.0 To: forrest-dev@xml.apache.org Subject: Re: site and book documents References: <20030107215014.14199.qmail@webmail-au.server-secure.com> <20030108042828.GC2942@expresso.localdomain> In-Reply-To: <20030108042828.GC2942@expresso.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Turner wrote: > On Wed, Jan 08, 2003 at 07:50:14AM +1000, Keiron Liddle wrote: >> >>Instead I thought that it could work with different files with the same >>format. Instead ref-tabs.xml and ref-book.xml are used to refer to the >>xml files to be included. A stylesheet can then convert the >>ref-tabs.xml into a document containing all the referenced xml >>documents, the combined document can then be converted as normal. > > > That does seem better. > personally I was thinking about this more along the lines of having a inside xdoc format itself. this would also allow for sort of binding-text (that has no meaning by itself) then we could have a transformer that pics up these 'inlines' and produces the full document to be processed further down the line 'as normal'. Persumably it would only inline the element... not fully sure whether we should have some xpath fragment identifier inside the link to include (is feasible but kinda breaks the SAX processing I think) I guess the next thing would be to allow for link-backs, so when you have the html version of some-part alone it could show links of larger agregated documents that embody it (this starts to sound like xlink, uh) > > I think it would be better to let the sitemap do all the XML merging, > transforming etc. > > At: > > http://cvs.apache.org/~jefft/forrest/samples/merge.tgz > > there is a sample project with a 'BookView' menu entry, which has a HTML > and PDF containing all merged content in the directory. Generated PDF at: > > http://cvs.apache.org/~jefft/forrest/samples/book.pdf > > This is implemented with the XPathDirectoryGenerator in Cocoon scratchpad. > > > > src="content/xdocs#/document/*"/> > > > > > > Nice. Stuff like this could reside in the forrest cvs as well, no? Next to having the forrest-seed-fresh-site we should maybe have a samples section as well? > > This isn't a full solution though, because formats other than doc-v11 won't be > integrated. That would be easy with a , but I'm not sure how to > aggregate dynamically. > interesting thought... maybe the merging should be defined on the intermediate (pre-skin format) > > --Jeff > > >>Anyway I think this sort of things should be considered. >> >>I have attached a sample of how it could be done. With an example in the fresh site. >> >>Keiron >> >> > > > -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ mpo@outerthought.org mpo@apache.org