This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: print output
- To: kwall at kurtwerks dot com, shelton at usq dot edu dot au
- Subject: Re: DOCBOOK-APPS: print output
- From: Bob Stayton <bobs at sco dot COM>
- Date: Sun, 17 Sep 2000 00:39:41 -0700 (PDT)
- Cc: docbook-apps at lists dot oasis-open dot org
> On Sat, Sep 16, 2000 at 04:54:31PM +1000, Phillip Shelton wrote:
> % Hello,
> %
> % Futher to my question on the print output of XML processing, does DOCKBOOK
> % have the tags for leaving things out for different audiences? ie do you have
> % one doc with the User Guide, Tech Guide, and context sensitive help? Or do
> % these have to be three seperate, different docs?
>
> And Kurt Wall further said:
>
> My approach is usually to create three different document wrappers
> that include the files I'm interested in. Then, I have a makefile
> that generates the document (format and content) in which I am
> interested. I can provide details via private email if you're willing
> to summarize them to the list.
And if you want to mark specific content within files for
different audiences, DocBook provides a set of effectivity
attributes for that purpose. These are included in the set
of common attributes that are available on most elements.
One of the effectivity attributes is "userlevel".
For example. You could do this:
<sect1 userlevel="techguide"><title>Some techie stuff</title>
...
and
<sect1 userlevel="userguide"><title>User guide stuff</title>
...
Then you modify your stylesheets to include
or exclude content based on the value of that attribute.
These attributes are declared in the DTD as CDATA,
which means you can use any string you like
for their values. For consistency, though, you should
enumerate a finite set of values you want to use
by redefining the parameter entity for the attribute in
a DTD customization layer. Then a validating parser
will spot any typos (and prevent accidental omissions
in your output).
The DocBook effectivity attributes enable this multi-doc
feature, but it's not trivial to implement. But then, such
documents won't be trivial to write and manage either. 8^)
bobs
Bob Stayton 400 Encinal Street
Publications Architect Santa Cruz, CA 95060
Technical Publications voice: (831) 427-7796
The Santa Cruz Operation, Inc. fax: (831) 429-1887
email: bobs@sco.com