[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 9:56 AM, "Tim Grantham" <tgrantham@timgrantham.com> wrote: > 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? The base shells are simply conveniences and reflect a useful default. They in no way represent a *normative* restriction. Every topic type can be configured to allow whatever topic types it wants as its children, as every topic type has it's own type-specific parameter entity that defines what subtopics it allows (if any). Users *already have to* create local shells simply because the if they *ever* want to use any new specialization or *not use* any module included by default, they *must* create local shells. Since it is a certainly that *any* production use of DITA will need to do one or both of these things at some point, it only makes sense to create local shells as the *first act* of implementing a production use of DITA, even if those shells are only copies of the TC-provided shells. Doing this prevents having to change the DTD URI/Public ID or schema location on *every topic* in your data set when you do realize you need to change your configurations. That would be incredibly disruptive and in some case prohibitively expensive. So prevent it by not allowing the problem to occur by creating local shells first thing. This is how DITA works. Everyone who uses DITA for production *must* understand this. If you don't do this it is only a matter of time before having not done it will bite you, possibly quite hard. DITA, like any powerful tool, requires some care and thought to how it is applied to specific situations. The requirement to create local shells is absolutely no different from the need to set up local components for any other non-trivial information management system or technology. 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]