Re: RE : TR : RE : DOCBOOK: full recursive docbook

[Bob Stayton <bobs@sco.com>]

On Tue, Mar 18, 2003 at 08:58:01PM +0100, Frédéric Glorieux wrote:
> > > 	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.
> 
> 	Customizing docbook is possible, but losing compatibility with
> standard tools is a great lost... this is the very last option.
> 	So my question is more precisely, do you plan for one day to
> support such constructions?

I seriously doubt that the DocBook Technical Committee would
permit mixing up the content hierarchy in the way  you
suggest.  You can always file a Request for Enhancement
at the DocBook SourceForge site, though.  8^)

> The goal I purchase is perhaps of general
> interest, a "leave-file" is an article, able to go in a one "file-tree"
> standard docbook, or to be the page of a website (static or dynamic).
> Very large software documentation project could find use of such things
> (sorry for the reference, I think of the infinite? Microsoft.msdn tree)

The DocBook hierarchy is extensive, but it is not infinite.

set -> book -> part-> articles -> sections

You may need to transform certain combinations of content
into a valid hierarchy.

> 	Before that, tricky things on sections are possible. Resolve the
> author ones, and the ones appended by engine. @id, order wishes, funny
> overriding effects possible, but not sure that authors will like it.
> 
> [xinclude]
> > I meant they could be generated.
> 
> 	Perhaps then xinclude should be reserved to authors [with no
> depth control], and engine use its own way.
> 
> [a file-tree structure, made for collaborative work in a
> "not-always-connected-world", where all folders are able to live alone
> or in parents]
> > OK.
> 	Is it an opinion? Is <toc/> usage not abusive?
> 
> > 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.
> 
> 	I imagine to use <ulink/> with relative url, #id support, and
> perhaps xpointer() if some want it. That means my own matcher of
> <ulink/> in case of no protocol://. The links will be broken after
> standard transformation, sad but not a too big problem. 
> 	Working on the URI string is perhaps enough for our simple needs
> (because there's also very complex needs, "semantic links" it's called,
> probably outside the docbook namespace). It could also be resolved in a
> publishing framework (cocoon like), or parsed for some SQL. 

Hope you can get it all working.

-- 

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