This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: [docbook-apps] how to add "extra" meta-info to a docbook document
- From: "Robert P. J. Day" <rpjday at mindspring dot com>
- To: Bob Stayton <bobs at sco dot com>
- Cc: "Juan R. Migoya" <jmigoya at telefonica dot net>, docbook apps list <docbook-apps at lists dot oasis-open dot org>
- Date: Thu, 28 Aug 2003 15:56:31 -0400 (EDT)
- Subject: Re: [docbook-apps] how to add "extra" meta-info to a docbook document
On Thu, 21 Aug 2003, Bob Stayton wrote:
> On Thu, Aug 21, 2003 at 01:48:32PM -0400, Robert P. J. Day wrote:
> > On Thu, 21 Aug 2003, Bob Stayton wrote:
> >
> > > If you are using the XSL stylesheets, you can
> > > use the 'condition' attribute as Juan says and
> > > use the profiling stylesheets, which do
> > > conditional text processing. See:
> > >
> > > http://www.sagehill.net/docbookxsl/Profiling.html
> > >
> > > But I'm not sure by what you meant with
> > >
> > > "embed non-DB info in a DB file"
> >
> > while the actual content of the manual that will be *printed*
> > will consist of only docbook tags, i'd like to bury non-docbook
> > tags in the manual that i can extract later for creating web pages
> > to describe those manuals.
> >
> > for example, a web page for any of my courses will contain a
> > "synopsis" of the course, as well as a "prerequisites" section.
> > these are not valid docbook tags, but i'd like to embed info like
> > that in the manual, so that *all* viewable material derived
> > from a manual is contained in the manual itself.
> >
> > as one solution, i guess i could just put all that info in
> > comments at the top of the docbook file. that's one way to
> > do it.
>
> Comments are a possibility, but they can get lost
> in tool chains that have more than one processing step.
>
> If you code your extra stuff in DocBook tags, then you
> can easily convert it to HTML for your webpages.
> So it still sounds like you could use profiling for this
> situation. For example, add this to your manual:
>
> <section condition="webpagestuff">
> <title>Synopsis</title>
> ...
> </section>
> <section condition="webpagestuff">
> <title>Prerequisites</title>
> ...
> </section>
i thought about this, and realized i wanted something a bit more
specific (which no doubt demonstrates that i'm *really* trying to bend
the rules here).
i don't want to use a conditional like "webpagestuff" since i want to
embed a number of different pieces of meta-info, and it's not sufficient
to tag that info with just a destination like "webpagestuff" since each
piece of meta-info might be destined for more than one output format:
1) HTML page outline
2) PDF brochure
and so on. i imagine having a number of meta-info bits like
- synopsis
- pre-requisites
- target audience
- related courses
and so on, and any one of these, while not used in the production
of the actual PDF manual, might be used in any of the other
marketing materials. so it seems necessary to tag each of these
with what they really are, like "synopsis", etc. in other words,
it really is document meta-info i'm trying to "hide" in the manual
and use only for generating related marketing material.
the best idea i've come up with is to actually bury it inside <bookinfo>
as a number of child elements, each of which will have a condition like
"synopsis", etc. there's just no immediate <bookinfo> child element that
leaps out as an obvious container, although i guess <abstract
condition="..."> comes as close as anything else.
maybe i've just never looked closely enough at all the DB elements,
but i've never seen one to semantically mark something as just ...
you know, "stuff". but i guess "abstract" is as close as i'm going
to get.
rday
To unsubscribe from this list, send a post to docbook-apps-unsubscribe@lists.oasis-open.org.