Re: TR : RE : DOCBOOK: full recursive docbook

[Bob Stayton <bobs@sco.com>]

On Tue, Mar 18, 2003 at 01:54:15PM +0100, Frédéric Glorieux wrote:
> 
> 	
> Thanks for the links.
> Was your server broken?

Not that I know of.  Did you have problems reaching it?

> I had time to read your references, what I wrote yesterday seems to be
> still useful.
> 
> > You can set up modular docbook files using recursive
> > 'section' elements.
> 
> The problem is, if authors want to write sort of articles, with some
> sectioning? (I know some who want it)
> I'm not sure to be able to realize consequences, but
> 	What about allow <article/> in <section/>?
> 	Or allow <part/> in <part/>?

Well, you would have to do some extensive customization
of the DocBook DTD and XSL stylesheets to support that.

> 
> >  You can use XInclude to assemble them
> > as needed.  
> > <?xml version="1.0"?>
> > <!DOCTYPE section PUBLIC ...>
> > <section id="startingpoint">
> > <title>Starting point</title>
> > <para>Stuff for this starting file</para>
> > <xi:include href="firstchild.xml" xmlns:xi="..." />
> > <xi:include href="secondchild.xml" xmlns:xi="..." />
> > ...
> > </section>
> 
> 	Do you mean that the <xi:include/> are generated by some app or
> server, or are they hard coded in each section file ? 

I meant they could be generated.

> 	In this case, I'm afraid of that. With a standard, users would
> like to use a standard processor. But I don't know if it's easy to
> control depth. For my case, generate a fast report for
> france/region/department (without all cities). I haven't found things on
> depth in the w3c recommendation for xinclude. For my fast own xsl
> implementation, I need some proprietary attributes, which mean change
> the
> section file for each publishing. So a dynamic solution seems to be
> needed.
> 
> > You can use olinks to form links between them.
> 
> 	Do you mean <olink/> for relative links like in website? I tried
> it for a documentation project, it's possible for developers, not the
> same for an architect, or an anthropologist.

The olinking used in the currently released version of
website is the old style entity olinks.  The XSL stylesheets
now support a newer olinking method that is easier to
use.  It still requires some setup by an administrator.
It is described in the reference I sent you.
 
> 	If my understanding is correct, that's why I'm oblige to propose
> what is following (in case of recursive section, waiting for
> section/article or a part/part/article solution).
> 
> A strict reference file-tree structure (could be virtual on some
> implementations like SQL, xml:db, or cocoon)
> /section
> 	section1.xml
> 	section2.xml
> 	section3.xml
> 	_toc.xml (a docbook <toc/> file to keep order in this section)
> 	/_config (with schemas, css, and other resources always useful
> after a fast copy/paste for working outdoor for example, or for browser
> navigation with no other applications)
> 	/section1 (contains nestable sections for section1)
> 		/config
> 		_toc.xml
> 		section1.1.xml
> 		section1.2.xml
> 		/section1.1
 
OK.

> 	This quite rigid tree structure seems to solve author's links as
> relative uri (../section1.1.xml), easy to understand (like in other html
> site).

I'm not clear on how you are forming your links.
You can't specify a <xref linkend="../section1.1.xml"/> in
your DocBook.  This looks more like XLink, which is not
implemented in DocBook.

> Publish transformations need very low corrections (*.xml 2
> *.html, check if resource present, id for one file generation, pdf ?).
> Don't have to maintain entity database for each added file.
> 	Rebuild a valid docbook everywhere seems to be possible with the
> same xsl
> document((document('_toc.xml')/toc/tocpart/tocentry[@id=$the-section-i-n
> eed]). 
> 	This is in tests on the <section/> granularity, but I would be
> glad to have <article/> as leaves.

Yes, but you won't get that without customizing the DTD
yourself.  
 
> > With such deep nesting, you will likely run into
> > issues of how to format titles for very deep
> > hierarchies.  The current XSL stylesheets only
> > go about 6 levels deep.
> 
> For this, happily, it's a detail. For html (which is first needed), I
> suppose you let an <h6/> at the end, a CSS class could be added to keep
> trace of level depth, and good luck to designers if they found styling
> idea for each depth (and find reader for that). The goal is to let it
> possible.

Sure.  8^)

-- 

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@sco.com