forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Standard DTD (was Re: [VOTE] FakeForrest is ready!)
Date Mon, 06 Jan 2003 04:33:03 GMT
Jeff Turner wrote:
> Nicola Ken Barozzi wrote:
> > Miles Elam wrote:
> > >Robert Koberg wrote:
> > >
> > [...]
> > 
> > >Simplified DocBook I think fits the role of a round peg here.
> > >
> > 
> > [...]
> > 
> > >Have you found the same to be true of the simplified version?
> > >
> > 
> > [...]
> > 
> > >It was not my intention to muddy the waters here, but I thought these 
> > >links might be interesting if for no other reason than to have another 
> > >schema with which to compare when making your own.
> > 
> > I think that we should embrace a standard instead of continuing on our 
> > own DTD.
> +1
> Or rather, make docv11 just another format that Forrest supports.

Forrest already does support any format you like. It is
easy to configure for other document types. At the
xml-commons project we have mixed types, some in full
DocBook some in document-v11 type. Using the project
sitemap.xmap and cocoon.xconf it is very easy.

However, we do need to make it even easier and platform
independent. I like Jeff's proposal below.

> Forrest needs a bit of restructuring to support multiple
> document types.
> Each new doctype requires (at least):
>  - schemas, currently in src/resources/schema/dtd
>  - XSLTs, in src/resources/skins/common/xslt
>  - catalog in src/resources/schema
>  - sitemap mods
> I was thinking we could package these up into RPM-like bundles,
> so users could download new doctype support as they need it.
> Forrest plugins. Hmm. Volunteers? :)

This would be truly excellent to have the infrastructure
for such plugins. In this way, business could add value
to Forrest and sell support packages for specialised
communities. Anyway, back to building the infrastructure.

Great idea Jeff, i will help.

How would it work? Would the forrest-dev community
maintain configuration files for each supported package
which define where Ant will get the separate pieces and
where to insert them into the local build?

Or would Forrest have separate cvs modules to hold copies
of the various released schemas, i.e. pre-prepared packages
of all the bits, that would be maintained by forrest-dev?


View raw message