[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: WG: [dita] Status of Nested Sections Issue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]