[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 for Aggregated Editing.doc) uploaded
Is the following contradiction resolvable? Eliot: > *all* users of DITA should ... as a matter of standard > practice ... [be] creating local shell DTDs as the > *first step* of any production use of DITA. Tim: > Why should we force users to design these shell DTDs? Is it a matter of different perceptions of who the DITA adopters are, and their expected skill & knowledge level? (With the attendant usability/adoption questions.) Is CM the only motivation & usefulness for ditabase, as Eliot suggests (below)? (CMS/elements vs. filesystem/documents.) Is there a reason that ditabase should not be considered an out-of-the-box shell DTD? > CMS systems, ... will > (must) have the infrastructure [for] e.g., generating a > single-instance document for editing and then breaking it > back up into individual topics. And then using the single-instance wrapper to persist that particular higher-level organization of the topics? I like saying the CMS vendors have the responsibility to do all the magic. I don't like depending on them to do it. As an alternative would it be easier for them to support round-tripping between a map (for publishing and to persist the higher-level organization into documents) and ditabase (or a wrapper using a custom shell DTD) for authoring? We have talked about the issue of persisting map-only attributes into a ditabase document so they can be picked up on the return trip. /B > -----Original Message----- > From: Tim Grantham [mailto:tgrantham@timgrantham.com] > Sent: Tuesday, March 10, 2009 11:57 AM > To: 'Eliot Kimber'; manning@rockley.com; 'dita' > Subject: RE: [dita] Groups - The Case for Aggregated Editing > (The Case for Aggregated Editing.doc) uploaded > > Hi, Eliot. > > The current DTD schemas (other than ditabase) allow only > aggregation and nesting of same-type topics: i.e. tasks > within tasks, concepts with concepts, etc. Hence, the need to > use ditabase for aggregration of topics of mixed types. How > would one use a shell DTD to allow some arbitrary nesting of > mixed topic types in a document? And, perhaps more > importantly, why should we force users to design these shell DTDs? > > Regards, > Tim > > > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Tuesday, March 10, 2009 11:35 AM > To: manning@rockley.com; dita > Subject: Re: [dita] Groups - The Case for Aggregated Editing > (The Case for Aggregated 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> > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that generates this mail. Follow this link to all your > TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > oups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS > TC that generates this mail. Follow this link to all your > TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]