Mike Feimster wrote: > The "Real Life" Migration to Stuctured Doc thread got me thinking. What is > better? A custom schema or one the "standards" such as Docbook or DITA.
DITA was designed by IBM for data interchange, so was never really intended as a data authoring structure. This can be confirmed by the creators of DITA at http://www-128.ibm.com/developerworks/xml/library/x-dita1/ where it states: > First, both SGML and XML are recognized as meta languages that allow > communities of data owners to describe their information assets in ways > that reflect how they develop, store, and process that information. > Because knowledge representation is so strongly related to corporate > cultures and community jargon, most attempts to define a universal DTD > have ended up either unused or unfinished. The ideal for information > interchange is to share the semantics and the transformational rules > for this information with other data-owning communities. So the bottom line is that DITA was never intended to replace a custom schema - it was designed to facilitate date exchange between arbitrary schemas. Nothing wrong with using DITA for that - it makes good sense in that role. DocBook is a worthless bucket of elements. Sorry. I had a look yesterday and quickly found two examples that were enough to reconfirm my opinion. The first was that footnotes can contain paras that can contain footnotes, so you could have bottomlessly recursive nested footnotes. No typesetting application is going to be able to make sense of that, so you're going to have to either tell it to ignore the ridiculous scenarios or remove them from the structure in the first place. The second was that table entries can nest tables in the same way. Good luck rendering that - FrameMaker won't even break an entry over a page, let alone support a handful of levels of tables nested in entries. Sure I could cut DocBook down, but when the starting point involves removing the ridiculous before I can even think of doing anything sensible, I lose patience fast. A far better approach (IMHO) is to start with the simplest schema you can and extend it as required. When someone asks for a new element or looser structure, make 'em justify it. Be ruthless about this - someone has to code for the changes, so make sure they really need it. Extending then becomes an engineering exercise - you can evaluate the impact and the cost of the proposed change, carry out regression testing on any XSLT or other system components, document the change properly, etc. If you must use a DocBook tool, create your schema using DocBook naming conventions and structures, but build it from the ground up, don't cut the big one down. Your analysis will be more thourough and your results better. Oh yeah, and make sure that when you finish playing with DocBook you wash your hands... Marcus