[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] (long) thoughts on creating a publishinginfrastructure
i've only skimmed juan's response so i'll just comment briefly on a couple of points (and i *really* appreciate the time it clearly took juan to pen his response -- i obviously have some reading to do and, in exchange, i'll some day summarize what approach i finally took). On Sat, 30 Aug 2003, Juan R. Migoya wrote: > Usually, for a manual with chapters (and apendix and the like) I put all > the stuff in subdirectories below the "manual main subdirectory" ... this is an obvious approach, but it's complicated by the fact that, since i want to custom-build manuals from smaller parts, it's not clear to which manual any chapter or section would really "belong". that's why the single-manual-with-subdirectory approach seems a bit awkward, and why i'm leaning toward some kind of central repository of all chapters/sections, out of which i just grab the parts i need for any manual. (it may be that i have a directory/subdirectory approach set up based on just *logical* relations to keep things organized, but that hierarchical structure in no way needs to represent any final manual content for any manual we produce.) also, since i want to be able to grab "modules" of information freely in building a manual, and the final manual should follow the standard chapter/section format, i can't even write these modules and hardcode them as <chapter>s or <section>s since, in one manual, a module could be chosen to be a self-contained chapter, while in another, it could be just a <section> of a chapter. one solution is to write all of these snippets as <section>s, but if a snippet is included at the top level, it's converted into a <chapter> automatically by the stylesheet. that wouldn't be hard, but it would have to be done to support this idea. [ASIDE: i could add to my "pidgin" docbook grammar a <module> element, which could just be converted to the appropriate DB element at the right time. it still represents the same idea -- the fact that i'm not writing explicit <chapter>s or <section>s, but rather generic information modules which i later combine to create a manual.] > Another approach I have taken with documents sharing a lot of > information is by means of a "condition" atribute. For example, you > could have "Linux Security" and "Linux Network Administration" as a one > manual made up from subdirectories. again, based on how many potential final manuals we might want to produce, i doubt i'll *ever* know ahead of time where a module might end up, or how many manuals it might become part of. so i'm still trying to design the infrastructure to be as flexible as possible. but i may have missed some of the details in your post that addressed that. as i said, i've just skimmed it so far, but i wanted to clarify some of my requirements. or am i being unreasonable in what i'm trying to do? rday
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]