Next in thread → Next in month →

AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded

From
"ReicoEyne EJSB"
Date
2007-11-09T22:33:24+00:00
ID
006601c82320$8446feb0$
Thread
AW: AW: [dita] Groups - DITA Proposed Feature #12021: Nesting sections (12021.html) uploaded
Hello Michael,

 

as promised have talked to some people from the 
machinery industry regarding the nested sections issue. And it seems that most 
point have been clearified. But may have now the opportunity to better explain 
why some still insist of reflecting the need of some sort of nexted 
sections.

 

This requirement is not connected to the planning of a 
document but with the way some authors are used to work.

 

I have to state that many - even in the machinery 
industry - totaly follow the one section level per topic concept and would never 
leave that track. Especially people who are addicted to information 
matting.

 

The wish of beeing able to split a section in 
subsections is comming from authors who write documentation in which the degree 
of complexity is growing while they are writing. It is always the same reason: 
An author is planning a document, splits it into topics, nests topics as 
required and starts to work. He/she writes the content of a topic, creates a 
couple of sections. While writing the sections he/she recognizes, that the 
structure is too flat and an additional level of hierarchy is 
needed.

Of course, the author now can restructure the topic and 
split the sections in separate topics to get the required structure. In theory 
that is ok and would solve the problem, but practically, the author gets pretty 
angry as restructuring a topic with a couple of sections into several topics 
needs far more time than to work how he/she is used to work by just adding a 
next level into the existing one.

And one point that may drive some crazy is the fact 
that maybe from 7 sections only one needs a deeper structure. And then to split 
that single topic in several to get the required nesting seems to be an overkill 
for some authors.

 

Hope I was able to reflect what challanges these 
people.

 

I fully agree, this is still a question of planning 
and this requirement should not challange us. But I just try to 
reflect what I hear from the field.

 

Best regards

 

Chris

Von: SeicoDyne DITA [mailto:] 

Gesendet: Dienstag, 30. Oktober 2007 15:43
An: 'Michael 
Priestley'
Cc: ; 'Grosso, 
Paul'
Betreff: AW: AW: [dita] Groups - DITA Proposed Feature #12021: 
Nesting sections (12021.html) uploaded

Yes 
Michael,

 

for the pilot they answered that they will go with what 
is available. So it was no longer the case for them in the 
pilot.

 

Nevertheless it will be a case again when they go for 
the productive part, especially regarding legacy 
data.

 

Maybe with new documents they can find a way, but it 
seems that Novartis can not port existing documents into a standard DITA 
structure without splitting the content into sensless small crumbs. 

 

Chris

Von: Michael Priestley 
[mailto:] 
Gesendet: Dienstag, 30. Oktober 2007 
15:19
An: SeicoDyne DITA
Cc: ; 
'Grosso, Paul'
Betreff: Re: AW: [dita] Groups - DITA Proposed Feature 
#12021: Nesting sections (12021.html) uploaded

Hi Chris, 

When we reviewed this proposal with Novartis, they said 
it met their needs - is that no longer the case? 

In my own experience, there are different reasons for 
grouping content together at authoring time and at delivery time. You may want 
topics grouped together in a single document for authoring, and split up for 
delivery, or vice versa. This is one of the issues addressed by the chunking 
feature in 1.1. 

So if a group 
decides not to nest topics during authoring, but then wants to nest sections 
with multiple levels of headings, I have to wonder why they aren't just nesting 
topics. But I didn't think that was Novartis's problem. 

As to whether "topics stand on their own" vs. nesting 
sections - I think there are always some topics that do not stand on their own - 
especially overview topics. Yet there are still reasons to sometimes manage them 
or treat them as topics separately - and sometimes that decision about whether 
it stands on its own is really one the reuser has to make, not the 
author. 

If the author uses topics 
for things that have unique titles (ie introduce new subjects), and nests topics 
when they need complex content, that leaves the door open for reusers to choose 
topics to reuse, and make their own decision. If the author doesn't use topics, 
then their content is not addressable or chunkable by others - and the reuse 
door is closed. 

Michael 
Priestley
Lead IBM DITA Architect 


http://dita.xml.org/blog/25 

  
  

    "SeicoDyne DITA" 
      <> 
      
10/30/2007 09:56 AM 

    
      
        
        

          
            
To

          Michael 
            Priestley/Toronto/IBM@IBMCA, "'Grosso, Paul'" 
            <> 
        

          
            
cc

          <> 
        

          
            
Subject

          AW: [dita] Groups - DITA Proposed 
            Feature #12021:  Nesting sections (12021.html)   
            uploaded

      
        
        

          
          

Yes indeed we had that case last year at Novartis, 
mainly regarding taking over legacy data. 
  

The main point that Novartis mentioned in 
that discussion was: 
1st they 
decided that each topic relates to one file in the database, 
2nd if they are going to split content of one topic 
in several topics, most of their content will loose the context. So content that 
belongs literally together would be split appart into separate files. This 
splitting would not only make the content highly difficult to manage, those 
topics would no longer be meaningful when they stand alone. 
Novartis has not yet decided if they go for DITA, 
Docbook or if they develop their own schema. 
From my last discussions I heared that they will go for DITA 
and call it DITA+ by bending or breaking our rules. As already mentioned, how 
Novartis will proceed is not yet decided, they are waiting to hear what the DITA 
TC decides. 
  
I would like to ask that question to the specialists of topic 
based authoring. What has more weight: 
- a topic is a unit of information that is meaningfull when it stands 
alone 
- a section in a topic is 
not alowed to contain sections 
  
Chris Kravogel 
  
  
SeicoDyne GmbH 
Eichenstrasse 16 
CH-6015 
Reussbühl 
Switzerland 
Tel: +41 41 534 66 97 
Mob: 
+41 78 790 66 97 
Skype: seicodyne 

  
www.seicodyne.com 
 
  
Member of the 
DITA Technical Committee 
Chairman of 
the DITA Machine Industry Subcommittee 
  

Von: Michael Priestley 
[mailto:] 
Gesendet: Dienstag, 30. Oktober 2007 
14:34
An: Grosso, Paul
Cc: 

Betreff: RE: [dita] Groups - DITA Proposed 
Feature #12021: Nesting sections (12021.html) uploaded

My recollection is that 
it was primarily for use in creating regular groupings of sections or of content 
under sections for specialization purposes. This was the use case for Novartis 
that Chris brought forward, and also the use case from Paul Prescod who 
co-designed the original proposal. 

For example, with these extra levels, you can model 
something like: 

<messagebody> 
<problem> (from section) 
<userresponse> (from bodydiv) 
      
 <analysis> (from section) 
      
 <recovery> 
... 
etc. 

There were some more complex use cases modeled in the original note 
series with Paul Prescod I believe. 

I think where people need to model freely titled 
nested divisions, the answer continues to be nesting topics rather than nesting 
sections - to try to prevent the bloating of topics into whole chapters or books 
of content (losing the constraints on topic size/complexity that are among the 
distinctions between DITA and DocBook). But where additional levels of 
organization are needed within a topic that do not represent new ideas or topics 
(and thus do not require new unique headings), I think this proposal gives the 
specializer considerably more freedom - as well as providing a general mechanism 
for grouping sections or blocks for the sake of conreffing a mixed range or for 
simplified conditional processing/metadata. 

Michael Priestley
Lead IBM DITA Architect 


http://dita.xml.org/blog/25 

  
  

    "Grosso, Paul" 
      <> 
      
10/30/2007 09:12 AM 
      

    

      
        
        

          
            
To

          <> 
        

          
            
cc

          
        

          
            
Subject

          RE: [dita] Groups - DITA Proposed 
            Feature #12021:  Nesting sections (12021.html)   
            uploaded

      
        
        

          
          

I was a little surprised to see this 
suggesting a bodydiv/sectiondiv
element but still not allowing sections to 
nest, which is what I
thought was meant by nesting sections.

I thought 
one of the drivers of this requirement was to be able
to model DocBook's 
nested sections more easily, but with the
suggested model, this would be even 
harder.

What are the benefits of this suggested model over simply 
allowing
section to contain section?

paul

> -----Original 
Message-----
> From:  
> 
[mailto:] 
> Sent: Tuesday, 2007 October 
30 7:15
> To: 
> Subject: [dita] Groups - 
DITA Proposed Feature #12021: 
> Nesting sections (12021.html) 
uploaded
> 
> This is the HTML version of proposal 12021
> 

>  -- Mr. Jim Earley
> 
> The document named DITA 
Proposed Feature #12021:  Nesting sections
> (12021.html) has been 
submitted by Mr. Jim Earley to the OASIS Darwin
> Information Typing 
Architecture (DITA) TC document repository.
> 
> Document 
Description:
> 
> 
> View Document Details:
> 
http://www.oasis-open.org/apps/org/workgroup/dita/document.php
> 
?document_id=25904
> 
> Download Document:  
> 
http://www.oasis-open.org/apps/org/workgroup/dita/download.php
> 
/25904/12021.html

---------------------------------------------------------------------
To 
unsubscribe from this mail list, you must leave the OASIS TC that
generates 
this mail.  You may a link to this group and all your TCs in 
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread → Next in month →