This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
[docbook] Re: RE : TR : RE : full recursive docbook
- From: Bob Stayton <bobs at sco dot com>
- To: Frédéric Glorieux <frederic dot glorieux at ajlsm dot com>
- Cc: docbook at lists dot oasis-open dot org
- Date: Tue, 18 Mar 2003 13:07:57 -0800
- Subject: [docbook] Re: RE : TR : RE : DOCBOOK: full recursive docbook
- References: <20030318102334.E15334@sco.com> <000001c2ed88$b1a52300$857ba8c0@FENELON>
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 at sco dot com