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



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]