Re: [docbook-apps] (long) thoughts on creating a publishinginfrastructure

["Robert P. J. Day" <rpjday at mindspring dot com>]

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


To unsubscribe from this list, send a post to docbook-apps-unsubscribe@lists.oasis-open.org.