Re: Fw: WG: [dita] Status of Nested Sections Issue

["W. Eliot Kimber" <ekimber@innodata-isogen.com>]

Don Day wrote:
> -----Ursprüngliche Nachricht-----
> Von: Christian Kravogel [mailto:christian.kravogel@seicodyne.ch]
> Gesendet: Dienstag, 10. Oktober 2006 17:03
> An: 'dita@lists.oasis-open.org'
> Betreff: RE: [dita] Status of Nested Sections Issue
> 
> Eliot
> 
> The issue of nested sections looks to me of something of high importance
> and
> the source for controversial discussions. I am working in technical
> authoring since 12 years, most time in the machine industry (elevators,
> escalators, etc.) and I noticed that if you give an author the ability to
> nest topics and to nest sections it will become a mess indeed and some will
> screw-up most structured content.
> 
> On the other hand, there are companies with special requirements and they
> absolutely need the ability to nest sections. The example of implementing
> legacy data is a very good approach. Different industries and different
> departments have different requirements. And when we think of DITA users,
> we
> should not limit that to the view of a technical author writing an
> installation instruction of a mechanical device or writing an API user
> manual.
> 
> Maybe we should not able section to nest, but we may add a separate block
> element that can be used for specializations to enable block nesting. E.g.
> the <div> element known from HTML (like you already mentioned).

I don't see that it makes that much difference whether you allow section 
to nest or add a new element type that is equivalent to section but that 
can nest.

In either case specializers can impose whatever local constraints they 
want, either disallowing nesting or creating a limited nesting level (by 
having unique specializations at each level) or by defining more 
semantic section types.

The question of what authors will do with the ability to nest and having 
two different ways to do things has always been a problem and will 
always be a problem. That's because it's an *editorial* problem, not a 
technology problem. Even if you disallow it (as the current DITA 
specification does) authors will just do something different if they 
have to.

That is, there is and can be no substitute for well-trained writers, 
appropriate editorial oversight, and clearly-defined editorial policies.

In addition, no matter what the DITA schemas say (or what any other 
schema designed for document authoring says), you *ALWAYS* need some 
sort of "validation application" that validates rules that cannot be 
expressed in a DTD or schema. This is either a separate application or a 
side effect of the error checking or failure behavior your processors 
provide. In either case, since you have to do this checking you can 
always add checks for editorial rules for things like section nesting, a 
requirement that there be at least two subsections under a section, that 
sort of thing.

In 1.1 I think that simply allowing section elements to nest is the 
simplest solution that meets the requirement, requiring no additional 
design, no additional element types, or anything.

Adding a new element type would involve more changes to the 
specification and open up more debate about exactly what the rules for 
that new elemen type should be. That level of design does need to be 
pushed off to a later version.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com