[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook] Ruminations on the future of DocBook
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]