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]

[docbook] RE : TR : RE : full recursive docbook


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


	Thanks for help.

-----------------------------------------------------------
Frédéric Glorieux               frederic dot glorieux at ajlsm dot com
AJLSM                           (33) 05 57 14 25 22
Conseil et dévelopement         17 rue Vital-Carles
en Informatique documentaire    33 000 Bordeaux
                                France




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