OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.



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]