--- Ross Gardler wrote: > OK, I've had a look at the build files. The > preprocessing stage is > actually optional. There are some things that don't > work if you don't do > it (like conrefs whatever they are). > Conrefs are strings pulled in from other files. So for example, instead of calling our product "Derby Version 10" everywhere, we can put the version number in a conref file, and call it whenever we want it in the dita files. That way we only change the version number in one place when he have a new release. You might call a conref an entity depending on what tools you use, but for DITA, we use a conref file. I suppose we can skip that step for now. > So, I propose that for this first instance we ignore > the preprocessing > step and just focus on getting the files into a > forrest site. > > I'm done for the night now so here's where I am up > to. I should get time > to look at this again in a few days time. In the > meantime if you want to > have a go at getting started, I (and others) will be > glad to answer > questions. > > ---- > > It seems that this will not be just one plugin, it > will be two. One (an > internal plugin) to generate the site.xml (or > book.xml) files and one > (and input plugin) to generate the XDocs. > > > The Dita Toolkit provides a set of XSL sheet sfor > building HTML or PDF > from DITA files. Since we do our own PDF generation > we'll focus on the HTML. > > Ignoring the preprocess stage for now, there are two > important targets: > > dita.map.xhtml Target > --------------------- > > This target is in ditatargets.xml > > This appears to be the target that creates the table > of contents: > > basedir="${dita.temp.dir}" > destdir="${output.dir}" > includes="${dita.input}" > > style="${dita.script.dir}${file.separator}map2htmtoc.xsl"> > expression="${dita.extname}" if="dita.extname"/> > from="*${dita.input.filename}" > to="*${args.xhtml.toc}.html"/> > > > > Since ths is the table of contents, it will create > our site.xml and will > belong in an internal plugin. > > Expressed as the beginnings of a Forrest pipeline > this is: > > > > src="resources/stylesheets/map2htmtoc.xsl"/> > > > > > > FIXME: What file are we generating from here? i.e. > what is the DITA > equivalent to our site.xml > > FIXME: What is the parameter DITAEXT for? > The ditaext value should be ".dita" The toc that gets generated is a simple html file. Here's a simplified version of the Derby Admin Guide toc file that gets generated: Server and Administration Guide I just removed a lot of bullets from that toc for simplicity... I dont know if thats what you can use, since it sounds like you would need an xml nav tree instead of an html one. In that case, maybe we should use the eclipse transform instead (also in ditatargets.xml). The eclipse transform is designed to create xhtml content with an xml nav tree (toc, in case you dont use the term, stands for table of contents, basically a nav tree). These files are usually thrown in an eclipse plugin that allows you to create an infocenter based on eclipse. But I think we can use them with Forrest instead. I'm attaching the file I attached earlier, but the xhtml version (is it the same?). Here is a simplified version of the xml toc that gets generated from the eclipse transform of the toolkit: (many bullets removed for simplicity) > dita.topics.xhtml > ----------------- > > This target is in ditatargets.xml > > This target is the "meat" of the transformation. It > provides the main > XSLT transformation: > > basedir="${dita.temp.dir}" > destdir="${output.dir}" > includes="${fullditatopc.list}" > extension=".html" > > style="${dita.script.dir}${file.separator}dita2xhtml.xsl"> > expression="${dita.extname}" > if="dita.extname"/> > expression="${dita.input.valfile}" > if="dita.input.valfile"/> > if="args.css"/> > expression="${args.csspath}" > if="args.csspath"/> > if="args.hdf"/> > if="args.hdr"/> > if="args.ftr"/> > expression="${args.draft}" if="args.draft"/> > expression="${args.artlbl}" if="args.artlbl"/> > > > This is what will provide our internal formats and > so this belongs in an > input plugin. > > Expressed as the beginnings of a Forrest pipeline > this is: > > > > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > expression="?????"/> > > src="{forrest:stylesheets}html2document.xml"/> > > > These ????? are just parameters. We dont use a css file for our project, for example. We dont enter any of these parameters at all for the Derby builds...