[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
On 3/10/09 7:55 AM, "manning@rockley.com" <manning@rockley.com> wrote: > Here is the paper on Aggregated Editing for Electronic Business > Documents discussed in last week's meeting. We are seeking your feedback, > concerns, issues, etc. > > Would it be possible to get your feedback by the end of March, the 31st? While I understand the problem this document presents (the general need to be able to author DITA-based documents as collections of topics, something most of my DITA-using clients face) I don't entirely understand either the barriers presented or the solution proposed. I think the document as written reflects a common misunderstanding of how DITA works. In short, there is *nothing* in the DITA standard that prevents authoring DITA-based documents as sets of nested topics. There is not even a requirement to use maps. In addition, this ability does *not* require the use of the ditabase document type to do this sort of aggregate editing. [In fact, ditabase should only be used for authoring in the very narrow usecase of needing to manage a number of otherwise unrelated topics as a single XML instance in data management environments where access control is applied to documents and not elements (e.g., filesystem-based data).] By the same token, the storage organization of topics *in no way* prevents the individual re-use of any topic by any map. Therefore, I don't see that there is a need to modify the DITA standard *in any way* to enable the type of editing that is needed by business documents (and by many other types of non-techdoc documents). All that is needed is appropriate shell DTDs that allow whatever combination of topic types is appropriate for a particular community of use. For example, irrespective of any specializations it might need (and it does absolutely need some), the Business Document subcommittee could usefully provide, as a convenience, shell DTDs that enable exactly the sort of topic nesting that is appropriate for those documents (doing what *all* users of DITA should do as a matter of standard practice, namely creating local shell DTDs as the *first step* of any production use of DITA). But note that, just like the base DITA shells are in no way normative or mandatory, such shells would be a convenience only. I do agree that it would be a benefit to the community if editors allowed the composite editing of topics otherwise organized only by maps. But I see that more as a function of CMS systems, which have the task of understanding the relationships among the components they manage and will (must) have the infrastructure to manipulate data as it goes in and comes out of the CMS, e.g., generating a single-instance document for editing and then breaking it back up into individual topics. I'm not sure its appropriate to expect editors to provide that sort of functionality, at least not entirely on their own. 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]