[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Groups - The Case for Aggregated Editing (The Case forAggregated Editing.doc) uploaded
In discussing this issue I think I've come to the realization that the problem is not with any lack in the DITA specification or the DITA mechanics. The problem is simply this: 1. The use of DITA in the way envisioned by the Business Documents SC (and by my Publishing clients) requires different configurations of nestable topics than is provided by any of the out-of-the-box shells. This represents a fundamentally different use pattern than that of most tech doc groups, who focus on modularity and re-use. Nevertheless it is a perfectly valid DITA use pattern and one that represents the quite possibly the largest potential use pattern, given that the volume of business documents and Publishing-type documents is orders of magnitude greater than the volume of technical documents will ever be. 2. The syntactic mechanics of defining new configurations, while *as easy as it could possibly be* in the context of DTD and XSD schema syntax, is still beyond the reasonable capabilities of anyone who isn't an XML and DITA specialist (or at least willing and able to work through my Specialization Tutorial, which is still essentially everyone). 3. In the absence of a way to *easily* create local shells and, possibly, local custom configurations, the use of DITA in any form for this non-modular use pattern except via ditabase is simply unrealistic to expect for any user community that is not at least large enough to have either a dedicated tools person or budget to hire a consultant. Note that the *practical* need to have local shells, even if they are merely unmodified copies of the TC-provided shells, is simply a fact that stems from the way XML works: if you change the configuration of a topic type's shell it's a new shell and has to have a new name and that name is part of the content of *every topic* of that type. This is coupled with the fact that *you will want to change your configuration sooner or later*, if only to remove those things you don't need from the default configuration. My assertion that best practice is to create local shells as the *first act* of production use of DITA is simply the logical implication of the fact given above: Eat the cost as early as possible in order to avoid much greater cost later. It's like changing the default password on your home router (or DOT road signs). But for Business Documents in particular, there is a larger problem: simple copies of the base shells won't work because the default shells only allow same-topic-type nesting. Using ditabase is at best unsatisfying because it allows *all topic types* to nest. Clearly Business Document creators need default shells (and specialized topic types) that represent a reasonable balance between constraint and flexibility but in any case allow a reasonable combination of topic types to nest (e.g., reference and task topics within concept topics along with probably some sort of generic "subsection" topic that avoids the whole concept/task/reference distinction but is still a bit more constrained than <topic>). In addition, even if the Business Documents SC provides such shells, savy (but not necessarily technical) users will quickly realize the value in further customization or specialization but will then get frustrated when they realize it requires a degree of minute technical knowledge they don't want to have (and don't think they need to have with other tools, like Word). At this point, an otherwise enthusiastic adopter becomes frustrated and disenchanted and decides Word is good enough. Given that analysis and reality (and I do think that the problem as stated in the subject document and as I've restated here is a real problem that needs to be taken seriously), then I think that the solution is relatively simple: Provide a tool or tools that hide the syntactic and mechanical complexity of creating new shells with new configurations. Such a tool should be completely possible for the very reason that the DITA standard explicitly constrains the syntactic mechanisms for creating and structuring shells. It is a 100% mechanical process that could be 100% automated such that a user, any user, can be given a UI that presents a set of available topic types and provides a visual mechanism for organizing them into a tree of allowed types, prompts for appropriate shell names and identifiers, and so on. (Such a UI could also produce map specializations that reflect the same constraints but in terms of specialized topicref elements.) Given such a tool implemented well, then it should not be any more difficult to define a local shell with the configuration you want than it is to create a new Word template. And through the magic of DITA, all such topics would still be completely interchangeable because DITA doesn't actually care about DTDs, only topic types and modules. The question then becomes: who will implement this tool? Without such a tool, the only options become: - Use the out-of-the-box shells, accepting the attendant problems of overgenerality and the need for future change to local shells. Even Business Document SC-provided shells will only be partially satisfying. - Limit the use of DITA to groups that can afford to create and manage their local configurations. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]