Structure/Schema - Custom or off the shelf?

[mcarr at allette.com.au]

Alan Houser wrote:

> Organizations are "successful" when they meet their business
> requirements as efficiently (time and $$$) as possible. I talk lots of
> people _out_ of migrating to XML for this reason.  I even occasionally
> say "you're doing just fine with MS Word."

Perhaps our roles are one of the reasons that ours views differ. My role
is typically to make migration efficient for companies that have some
committment to going to XML in the first place, so I do very few "Word vs.
XML" deliberations.

> If you're migrating to XML, *not* using FrameMaker, and have print/PDF
> as one of your output requirements, take a good hard look at using or
> leveraging a standard information model, like DocBook or DITA. Printing
> XML using XSL-FO is one of the most difficult tasks you will face, and
> leveraging the XSLT transforms for an off-the-shelf DTD is likely to
> save a very substantial amount of development time.

Creating XSL-FO is easy - I just tell a programmer what I want. Before you
dismiss that as glib consider an alternative approach - say, using Perl to
convert the XML to RTF. Either of these approaches are tasks for a
programmer and using appropriate resources is at least as important as
using the right structure. This should be apparent - you can be pretty
sure that the people who wrote the XSL for the OTS schemas were
programmers, not writers.

Also, XSL-FO is typically used when the print process is a terminal use of
the data. If that's all you need, then another approach is to convert the
XML into another structure that is more Frame-friendly. There are ways of
making publishing the data less difficult.

> By the way, I never recommend starting out with out-of-the-box DocBook
> -- if you use DocBook, I always favor constraining it. My observation
> comes from a couple of implementations in which the client said "no
> thanks, we're not going to bother constraining DocBook." Those clients
> were creating fairly homogeneous information deliverables, and it turned
> out that the writers were far more successful at marking up these
> deliverables than I had expected, because they did so by example. Just
> an observation.

They may have been equally successful, but they weren't *more* successful
than if the structure was more concise, so what did they gain? As far as I
can see, they saved the cost of cutting it down at the expense of
increasing the complexity of adding new writers needing to mark up by
example. I'd suggest that's a pretty poor decision.

> It's also important to remember that a DTD alone isn't sufficient to
> structure your data. A DTD cannot specify all possible constraints (the
> recent "nesting level" discussion is just one example), nor can it
> prevent the use of valid but semantically-incorrect tags. There always
> needs to be a human element for markup review and quality control.

There are ways of dealing with issues like nesting, but overall I agree -
humans need to play a role. Unfortunately, it's mostly to catch the
mistakes made by other humans... ;-)


Marcus