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

[Don Day <dond@us.ibm.com>]

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