Re: [dita] When does DITA Document Type Not Meet Requirements?

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

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

eliot@innodata-isogen.com
www.innodata-isogen.com