This is the mail archive of the
mailing list for the DocBook project.
Re: [docbook] Ruminations on the future of DocBook
- From: Tobias Reif <tobiasreif at pinkjuice dot com>
- To: docbook at lists dot oasis-open dot org
- Cc: Norman Walsh <ndw at nwalsh dot com>
- Date: Fri, 30 May 2003 11:24:16 +0200
- Subject: Re: [docbook] Ruminations on the future of DocBook
- References: <firstname.lastname@example.org>
Norman Walsh wrote:
> It's hard to articulate exactly why. I think it's because DocBook is
> showing its age. There comes a point in the life cycle of any system
> when adding one more patch is the wrong solution to every problem.
> Eventually, it's time to rethink, refactor, and rewrite.
> For DocBook, I think that time has come.
I agree. I think a fresh rewrite, ideally without having to care (too
much) about backwards compatibility, promises to be an extremely
The new DocBook could be much more orthogonal, coherent, modern, and clean.
I hope it ...
* will depend less on any specific schema language such as DTD (no
schema supplied attribute values etc).
* will not contain any presentational features.
* will be as media-independent as possible.
* will continue to be useful for a wide range of scenarios, from tiny
howtos to large book projects. (the latter could mean that the number or
inline elements could not be decreased significantly)
To address some of your points from
"If we were starting over, I think we'd approach the problem much
"We'd use XML."
"We'd use RELAX-NG."
This seems to be a very fine schema language, but there are others. I
hope that DocBook won't again depend on one specific schema language.
"We'd design for the web."
I suggest to forget the web when designing DocBook, as much as possible.
If DocBook stops being media-independent, I will stop using it. If I
author for one single specific medium, eg the web, I use a
media-specific language, eg XHTML. If I need media-independence, I can
"We'd design for regularity and consistency at the current scale."
"We'd almost certinaly put it in a namespace."
That's good. XSLT, SVG, all are in their namespace, and it's no problem.
"Perhaps controversially, we might allow foreign namespace elements to
creep in. We might, for example allow Dublin Core in metadata."
Could be OK.
DocBook should not care about presentation.
It should be purely about semantics and structure.
DocBook should not care about target formats or target media (satisfying
this would automatically satisfy the above). If you include many web
specific features, then Docbook will be less useful, and it might become
a little obsolete again, as soon as there are new media becoming as
important as the web. If DocBook stays (and becomes even more)
media-independent, it won't have to catch up with the growing list of
media (print, web, speech, braille, and more things not yet heard of).
But the main motivation for this is that media-independence is the only
reason why many people use DocBook.
Overall, if the next DocBook will be as good as I think it could be,
then I'll be happy to support it with
One specific point: XLink might be a candidate for the linking
mechanism; SVG uses it for example.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org