[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: WG: [dita] Status of Nested Sections Issue
On behalf of Chris Kravogel, who is having TC mail list issues. ----- Forwarded by Don Day/Austin/IBM on 10/17/2006 08:17 AM ----- "Christian Kravogel" <christian.kravog To el@seicodyne.ch> Don Day/Austin/IBM@IBMUS cc 10/17/2006 08:10 AM Subject WG: [dita] Status of Nested Sections Issue Don Enclosed some ideas from my side. Thanks Chris SeicoDyne GmbH Eichenstrasse 16 CH-6015 Reussbühl Switzerland Tel: +41 41 534 66 97 Mob: +41 78 790 66 97 www.seicodyne.com christian.kravogel@seicodyne.com -----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). The code may look at this: <!ELEMENT div (%div.cnt;)* > <!ATTLIST div spectitle CDATA #IMPLIED %univ-atts; outputclass CDATA #IMPLIED > <!ENTITY % div.cnt "#PCDATA | %div; | %basic.ph; | %basic.block; | %title; | %txt.incl; | %data.elements.incl; | %foreign.unknown.incl;"> <!ATTLIST div %global-atts; class CDATA "- topic/div " > This would enable information architects to develop topics for special needs but leaves the base structure as it is recommended in a good authoring practice. What do you think? Cheers, Chris Chris Kravogel SeicoDyne GmbH Eichenstrasse 16 6015 Reussbühl Switzerland T: +41 41 534 66 97 www.seicodyne.ch -----Ursprüngliche Nachricht----- Von: W. Eliot Kimber [mailto:ekimber@innodata-isogen.com] Gesendet: Montag, 9. Oktober 2006 18:28 An: dita@lists.oasis-open.org Betreff: [dita] Status of Nested Sections Issue In some work we (Innodata Isogen) is doing, we're finding the lack of nestable sections to be a very serious impediment to using DITA effectively for marking up legacy documents as-is (that is, without re-authoring the content to account for poor writing practice in the original). I reviewed the list to see what the disposition of this issue is. I saw several proposals but no disposition. To mind the obvious and simplest thing to do is to allow sections to nest in 1.1. What do I need to do to formally submit this as a proposal for a vote? The particular use case in this instance is a semiconductor data sheet, where the entire sheet is clearly one topic but no subsection of the sheet can be considered a topic in any rhetorical sense because, by definition, the information in each subsection only applies to the specific component. It would be prima-facie nonsense to make, for example, the "Min/Max" section of the data sheet a separate topic because that is information that would never be useful either for re-use or as a topic included in some other package not associated with the overall component. Even more so for any subdivisions within the major sections of the data sheet. And of course the use case for fairly typical technical manuals seems obvious to me as well but that certainly wasn't in evidence in the message history. In essence the notion that information that is not rhetorically a topic should be marked as a topic just seems so fundamentally wrong to me, as a technical writer and as a XML practitioner, that I marvel that anyone involved with DITA would even suggest it. As Paul Prescode pointed out, to mark things up as topics that are not topics is to erode the whole value of topics as a concept. Cheers, E. -- 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]