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]

Re: [docbook-apps] Re: One TOC and one glossary for multiple docbook XML files


Bob:

Can you follow the same model for bibliography as the one you indicate for
the glossary?

Carlos
--
Carlos E. Araya
WebCT Administrator - Trainer
California Virtual Campus, Region 1
C/O De Anza College
21250 Stevens Creek Blvd.
Cupertino, CA 95014
(p) 408 257 0482 (f) 408 255 4406
<icq> 5140783  <aim>carlosed1974
web (work): http://www.cvc1.org
web (personal): http://silverwolf-net.net/
Sig:
(7) It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all
three).
from RFC 1925: The Twelve Networking Truths
----- Original Message -----
From: "Bob Stayton" <bobs at sco dot com>
To: "Yan Bilik" <yan dot bilik at wanadoomaps dot com>
Cc: <docbook-apps at lists dot oasis-open dot org>
Sent: Friday, April 11, 2003 09:37
Subject: Re: [docbook-apps] Re: One TOC and one glossary for multiple
docbook XML files


> On Fri, Apr 11, 2003 at 09:07:56AM +0200, Yan Bilik wrote:
> > > From : Bob Stayton [mailto:bobs at sco dot com]
> > >
> > > Since you are using olinks, you could use the olink targets
> > > database to create a master table of contents.  One could
> > > write an XSL stylesheet that generates a DocBook <toc>
> > > with <tocentry> elements from the database, following the DocBook DTD
> > > for <toc>.
> >
> > Yes. The only problem is that the master target database does not have
> > any information related to order of documents. It only describes the
> > directories structure.
>
> That's correct.
>
> > Thus, without this knowledge of how documents must be chained (I mean:
> > which XML should be the preface, which one the first chapter, etc...),
> > the main TOC would have a structure that follows the directory
> > structures, and not the chapters order...
> > I miss something: a document that contains both information (which XML
> > to proceed, their identifier, where to create the HTML, and how HTML
> > should be ordered in the main TOC).
> > Hum...
>
> Yes, that structure doesn't exist in any of the documents,
> nor in the olink database.  It is in your head, and must
> be expressed somehow for a process to work with.  8^)
>
> > I also thought about a main document which would include the other ones.
> > A book, for example, with a structure like this one:
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
> > "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd";>
> > <book id="onlyone" xmlns:xi="http://www.w3.org/2001/XInclude";>
> >   <title>The main doc</title>
> >   <xi:include href="xmldocs/doc1.xml" />
> >   <xi:include href="xmldocs/doc2.xml" />
> >   <xi:include href="xmldocs/doc3.xml" />
> > </book>
> >
> > But in such a case, I have two problems:
> > - my original XML docs have sections with identifiers, and I do not know
> > if this identifier is unique once merged into my main document. In fact,
> > as many of my XML documents share the same internal structure, they do
> > use the same sections identifiers.
> > - the olinks would not work anymore.
>
> Yes, those are real problems when trying to merge
> independent documents.
>
> One approach you might consider is authoring a skeleton
> <toc> document that can be used to drive the generation
> of the full <toc>.  The skeleton toc would capture the
> structure you want for your separate documents, and use the
> targetdoc attribute as the identifier for each document.
> A stylesheet would open both the skeleton toc and the
> target database.  It would process the skeleton toc as
> the main document, and for each targetdoc it encounters,
> it would extract the <div> element structure from the
> correct <document> element in the target database, and
> make tocentry elements for them.  That way you could
> still use olinks in each tocentry.
>
> I'm interested in helping develop such a stylesheet.
> Could you send me (offlist) an example of
> your target database and a basic outline of how
> you want the documents structured?
>
> > I do not have any idea about the master glossary document. Should I
> > write glossary entries directly inside it, with olinks ? Or should I
> > collect local glossaries among my XML docs in order to build the master
> > glossary ??
>
> For the glossary, I can see lots of problems trying to
> merge glossary entries.  What about repeated entries?
> Or similar entries?  You should consider instead using
> the glossary collection feature of DocBook.  That lets
> you keep a central glossary database that your individual
> documents can draw upon for terms.  Then you just need
> to have a link to a rendered version of your glossary
> collection file.  See the "Glossary database" section in:
> http://www.sagehill.net/xml/docbookxsl/SolveProblems.html
>
> --
>
> Bob Stayton                                 400 Encinal Street
> Publications Architect                      Santa Cruz, CA  95060
> Technical Publications                      voice: (831) 427-7796
> The SCO Group                               fax:   (831) 429-1887
>                                             email: bobs at sco dot com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe at lists dot oasis-open dot org
> For additional commands, e-mail: docbook-apps-help at lists dot oasis-open dot org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe at lists dot oasis-open dot org
For additional commands, e-mail: docbook-apps-help at lists dot oasis-open dot org


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