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 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]