Return-Path: Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org Received: (qmail 40575 invoked by uid 500); 8 Jan 2003 10:04:38 -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 40564 invoked from network); 8 Jan 2003 10:04:37 -0000 Received: from new-smtp1.ihug.com.au (203.109.250.27) by daedalus.apache.org with SMTP; 8 Jan 2003 10:04:37 -0000 Received: from p81-apx1.syd.ihug.com.au (expresso.localdomain) [203.173.140.81] by new-smtp1.ihug.com.au with esmtp (Exim 3.22 #1 (Debian)) id 18WD4o-0007v9-00; Wed, 08 Jan 2003 21:04:47 +1100 Received: from jeff by expresso.localdomain with local (Exim 3.35 #1 (Debian)) id 18WD7A-000351-00 for ; Wed, 08 Jan 2003 21:07:12 +1100 Date: Wed, 8 Jan 2003 21:07:11 +1100 From: Jeff Turner To: forrest-dev@xml.apache.org Subject: Re: site and book documents Message-ID: <20030108100711.GD2942@expresso.localdomain> Mail-Followup-To: forrest-dev@xml.apache.org References: <20030107215014.14199.qmail@webmail-au.server-secure.com> <20030108042828.GC2942@expresso.localdomain> <3E1BE409.1020004@outerthought.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1BE409.1020004@outerthought.org> User-Agent: Mutt/1.4i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, Jan 08, 2003 at 09:40:41AM +0100, Marc Portier wrote: > > > 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. XInclude then? > 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) > ... > >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? It's really just a custom sitemap and stylesheet added to a 'seed' site. If this were in CVS, we'd need to basically duplicate the seed files for every 'sample'. Keeping samples on a webserver somewhere would be better.. Actually, I've been thinking how we could use Forrest to make Cocoon development easier. By adding a build.xml to the seed site, we have an ideal environment for quickly developing components like Transformers. The Java code, XML documentation and sitemap example are all contained in one small package. > >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) Yes. --Jeff