RE: [docbook] Ruminations on the future of DocBook

["Wills, Robert" <Robert dot Wills at sts dot co dot uk>]

>More thinking is definitely in order. By more minds than mine,
>which is why I'm publishing these essays now.

I for one would be an enthusiastic early adopter of a simpler, more
consistent DocBook along these lines.

And if you're inviting suggestions...

I would like to use an object-oriented approach when dealing with DocBook
grammars and instance documents, as OO concepts seem to fit the problem
domain very well. I'd like to inherit the grammar for my specific
application from a generic one by outlawing markup elements I don't want and
deriving new elements with special semantics from existing generic ones. And
I'd like to do all this in familiar programming languages, e.g. Java & C++.
Perhaps as well as a RELAX-NG or other schema language definition we could
also have a UML class model representation of the new DocBook?

I work with a software development group which is now using DocBook
successfully to produce user manuals. We've had the usual difficulties with
choice of editors, figuring out which tags to use, etc. but the biggest snag
was the unwillingness of team members to get to grips with XSLT or the
modular DTD. We're now using home-grown Java code to parse, validate and
transform sources to XSL:FO purely so that developers are more comfortable
making customizations using a familiar technology. I'm sure we could attract
a wider user community for DocBook by providing tool-chains that were easier
to set up, even if their customizability was much less than a full
XSLT-based system.

Robert Wills

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