Structure/Schema - Custom or off the shelf?

[mcarr at allette.com.au]

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