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] A theoretic limitation (was: thoughts oncreating a publishing infrastructure)


Hi Robert and all,

I suggest Robert to take a look at Borges
(http://www.linux-mandrake.com/en/doc/project/Borges/) which is the
system we developed at mandrake to manage our documentation, and we
packaged for others to use as well.

This system should answer all of your needs (and more) but one: modules
root elements masquerading (i.e. mapping a sect1 to a chapter).

I have been considering this feature before but not implemented it
because it proved difficult to generalize and of limited practical
interest. Though if this is the one stopper that prevents you from
adopting Borges, I'll be glad to discuss on the technical ways to
achieve that.

I think that if mapping is only required on a limited set of structuring
elements (say: article, chapter, sect*, appendix, section, preface) it
should be feasible to implement an algorithm that transforms one element
to another (when DTD possible).

Camille.


Le dim 31/08/2003 à 11:09, Juan R. Migoya a écrit :
> Bob Stayton wrote:
> 
> >Have you looked at using XIncludes instead of entities?
> >If you use an XInclude processor that handles the XPointer
> >syntax (like xsltproc), XIncludes could solve your problem of
> >turning a <chapter> module into a <section>.
> >
> >For example, you write a module that looks like this:
> >
> ><?xml version="1.0" encoding="utf-8"?>
> ><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
> ><chapter id="mychapter">
> ><title >My Module Title</title>
> ><para>This module does ...</para>
> >...
> ></chapter>
> >
> >Then your master book document could pull its content
> >into a section container, excluding the <chapter> container:
> >
> I am in the process of migrating from DSSSL to XSL, X*, so I can't help 
> here, but
> it sounds great, and I will try it for myself. Thanks for the advice.
> 
> But, after reading the response from Rober P. J. Day to my answer, I began
> to suspect there is a theoretic limitation to what he wants to do:
> 
> You want a piece of document to be inserted in ANY node of the docbook
> structure. *I think you can't design such a submodule*.
> 
> The answer from Bob is quite explanative: he suggest a procedure to convert
> <chapter> to <section> (and vice versa I guess). Surely, we could use this
> procedure to several pairs of docbook tags. But could you transform a
> <refentry> into a <chapter> whit the mentioned procedure? Obviously not.
> Even more: if it were some <element> allowed as a child of a <section>
> but not as a child of a <chapter>, wich *may* be not the case in Docbook
> but it is possible nowadays, you couldn't do the trick.
> 
>  From the Robert message I guess he wants a lot of flexibility here. But I
> have serious doubts about the subject. Some SGML/XML gurus here
> in this list surely will have better explanations and conclusions than I 
> have.
> 
> After what I say above, I must admit that *yes*: If you have structured text
> then you can do what you want provided you have or build the adecuated
> software. If this is the way Robert would like to take, I would suggest
> to open another thread about how to structure the documentation and
> what custom procedures you should build in order to have a multi
> level structured fully rehusable pool of documentation.
> 
> Best regards,
> Juan R. Migoya
> Spain
> 
> 
> 
> 
> To unsubscribe from this list, send a post to docbook-apps-unsubscribe@lists.oasis-open.org.


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


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