This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

TR : RE : full recursive docbook


	
Thanks for the links.
Was your server broken?
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/>?


>  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 ? 
	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.

	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

	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). 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[ at id=$the-section-i-n
eed]). 
	This is in tests on the <section/> granularity, but I would be
glad to have <article/> as leaves.

> 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.





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