MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] When does DITA Document Type Not Meet Requirements?
From: "W. Eliot Kimber" <>
To: DITA TC list <>
Date: Wed, 08 Dec 2004 09:48:16 -0600
JoAnn Hackos wrote:
> I'm very concerned about a consulting approach that tries to maintain
> all the variations that have over eons been imposed on a documentation
> set.
This definitely *does not* describe my approach to XML application design.
While we (Innodata Isogen) are usually not hired as information
designers, as a professional technical writer I always bring my skills
and experience to the table. For example, when doing a format analysis,
I will, as a matter of course, question any formatting artifact that
does not seem to suit a particular purpose.
At the same time, I am usually working with clients who have one or more
of the following characteristics:
- They have invested heavily in their information presentation design
and have not hired us to second guess it.
- They are implementing a corporate look-and-feel, often being developed
by marketing consultants and we have been explicitly instructed not to
question it, no matter how patently ridiculous it might be.
- They are implementing government, military, or industry presentation
styles that have been essentially unchanged for 50 years or more.
That is, most of our clients tend to be large corporations with complex
cultural, business, and organizational reasons for their presentation
styles, limiting their flexibility or willingness to entertain
suggestions for refinements to their design.
But *under no circumstances* do I structure a DTD simply to propogate
particular formatting effects. The primary focus of DTD analysis and
design is to define the most appropriate structures for enabling
authoring, interchange, processing, re-use, and presentation. One of the
things I try very hard to do is to eliminate unnecessary or non-sensical
distinctions at the element type level, doing my best to generalize the
markup design (sometimes followed by appropriate specialization). But I
also try to make sure that essential distinctions are in fact made. I
also try to ensure that specialized element types reflect the
appropriate generalization in anticipation of likely future requirements.
For example, I just did a project for a customer where I significantly
simplified their DTD by removing unnecessary element type distinctions,
some of which had been driven by formatting distinctions that could be
made by context alone.
At the same time, I do not hesitate to add or suggest new structures
that add value to the system.
Behind this is the nemesis of "conversion" rather than rethinking,
> simplification, and minimalism. Perhaps clients would be better served
> by working with a design consultant rather than trying to convert all
> previous format quirks into DTDs. Most of these nested lists and
> subparts or subparts carry no advantage to the reader. We try to point
> out to clients that they really don't need to write that way.
I don't doubt that there are any number of XML practitioners out there
that approach projects in this way, blindly transliterating legacy
structures to XML, largely because I've had to clean up after them.
But I *am not one of them*--if anything I said in my posts suggests that
then I have not been clear.
My goal as an XML application designer is always to find the simplest
solution that provides the best solution to the requirements at hand.
All I've been saying is that for most of my clients, DITA as defined has
not been that solution--there has always been something they really
needed that can't be done with DITA as currently defined. I very much
want DITA to be a solution because it offers lots of value. But I also
realize that my constituency has different requirements and different
weights for requirements then many other potential users of DITA. I will
not shoehorn a client into a DITA-based solution just for the purpose of
using DITA, any more than I would force them to use any other technology
that wasn't a good fit to their needs.
This is no different than my approach to the use of XSL-FO: FO has
tremendous advantage but it doesn't solve all problems. Therefore, the
first question that has to be answered when designing an XML rendition
process is "can XSL-FO satisfy the requirements?". If it can, then
great, but if it can't, first we see if the requirements can be trimmed
back so that FO will work. If that can't be done then we look somewhere
else. It's the same with DITA or any other standard technology.
Cheers,
E.
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
www.innodata-isogen.com
