Structure/Schema - Custom or off the shelf?

[Alan Houser]

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."
 
I think the answer to the "custom or off-the-shelf" question differs 
with each customer's business requirements and even tool choice. For 
FrameMaker XML implementations, I'm much more likely to recommend 
designing your own DTD. FrameMaker handles the "hard" part of publishing 
XML (printing it), and provides a reasonable environment for building 
your information model (the structured EDD). It's also relatively 
difficult to get FrameMaker to play with most off-the-shelf DTDs,  
mainly because of the constraints of the FrameMaker import/export model. 
Rolling your own DTD becomes an attractive option with FrameMaker.

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.

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.

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.

-Alan


eric.dunn at ca.transport.bombardier.com wrote:
>
> Alan Houser wrote:
> > Regarding DocBook -- I acknowledge that it's big, and has a "designed by
> > committee" feel. However, I've seen too many companies use it
> > successfully to dismiss it.
>
> Many companies use MSWord and other less than ideal tools. Also 
> strongly depends on your definition of "successfully".
>
> > Having a set of extensible XSLT
> > transformations is absolutely invaluable -- not for the easy stuff, like
> > transforming "<title>" to "<h1>", but for the hard stuff, like building
> > a back-of-the-book index. Try writing that XSLT code from scratch.
>
> True. But, any self respecting implementer should see how they can 
> create their own work environment that can perhaps integrate with and 
> leverage the existing tools.
>
> > DocBook's size isn't necessarily the problem it may appear to be.
> > Authors tend to learn markup languages by example. Their approach is
> > typically "here's how we mark up a help topic in DocBook" (bottom-up),
> > as opposed to "which of DocBook's 400 elements do I need to mark up a
> > help topic?" (top-down).
>
> Another Yuck. Many people use MSWord styles in much the same manner. 
> What's the point of adopting a structured environment if your not 
> going to adopt a design that actually structures and controls your data?
>
> "here's how we mark up a help topic in DocBook" Should be a very easy 
> exercise to take and create a working subset of Docbook. Then there's 
> little authors can do wrong.
>
> Eric L. Dunn
> Senior Technical Writer
>
> PS: If this makes it to the list could someone give me a heads up?
>
>

-- 
---
Alan Houser, President
Group Wellesley, Inc.
412-363-3481
www.groupwellesley.com