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
[EMAIL PROTECTED] 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
_______________________________________________
You are currently subscribed to Framers as [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
