[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?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]