Re: [docbook] Ruminations on the future of DocBook

[Tobias Reif <tobiasreif at pinkjuice dot com>]

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

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
http://norman.walsh.name/2003/05/21/docbook :

"If we were starting over, I think we'd approach the problem much 
differently:"

"We'd use XML."

agreed :)

"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 
use DocBook.

"We'd design for regularity and consistency at the current scale."

Sounds good.

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

IMHO:

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
http://www.pinkjuice.com/joocs/

One specific point: XLink might be a candidate for the linking 
mechanism; SVG uses it for example.

Tobi

--
http://www.pinkjuice.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org