This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[docbook-apps] Multi-part document, multiple stylesheets


First off, thank yo to Bob and Michael. I've since switched over to Saxon, XIncluder, and Ant and most of the technological issues seem to have finally been taken care of. (And yes, I am using Debian. Good eye. I take it you are too. <g>)

However, I'm now running into a design problem that I'd also appreciate some help on.

I have/will be building a <set> of books, probably around 5 although at the moment I just have one marked up for testing. The source is in a series of XML files across a few directories, brought together via XIncludes. (set.xml is mostly xi:include directives to various books, each of which is mostly xi:include directives to various chapters/articles.)

Although all are similar, the outputs for each (HTML and PDF, just dealing with HTML for now) will be just different enough that I need to use separate customization XSL files for them. (Different CSS links, for instance.) OK, fine, run each one separately via Ant. Except that I also want to generate an index/cover page for the whole set. That requires running the scripts against the top set.xml file. Of course, that also then generates files for the rest of the tree, which will not have the right customizations set.

In addition, I'm using XIncluder as a preprocessor to generate a single, complete document before passing that to the rest of the targets. I originally was using Xerces directly in the Saxon command, but the version of Xerces I have still has the bug in its XInclude URI string (2001 vs. 2003). Being a nitpicky purist I didn't want to go through and put "wrong" namespaces in all of my documents, but I'm not sure how to link XIncluder in directly. That means that in order to run each book separately, I'd have to run XIncluder on a portion of the source tree first for each one. Since neither XIncluder nor Saxon is particularly speedy, that results in a very slow, very ugly build process. I don't even want to contemplate how messy it would get once I added FO/PDF output as well.

So the best I can come up with right now for the build process is something like:

- XIncluder to resolve whole set.
- Saxon on whole set to generate set's index.html.
- XIncluder to resolve book A.
- XIncluder to resolve book B.
- XIncluder to resolve book C.
- Saxon on book A temp file, overwrite what set generated.
- Saxon on book B temp file, overwrite what set generated.
- Saxon on book C temp file, overwrite what set generated.

My mind is screaming at me that there has got to be a better, cleaner, less ugly way than that. Can anyone point me in the direction of what that would be? Many thanks.

--
Larry Garfield			AIM: LOLG42
larry@garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]