|Esrig, Bruce (Bruce)||Nov 7, 2005 12:27 pm|
|Subject:||RE: [dita] rich topic with nested divisions|
|From:||Esrig, Bruce (Bruce) (esr...@lucent.com)|
|Date:||Nov 7, 2005 12:27:14 pm|
Continuing this proposal, would we have ...
- a rich topic (called <article> in Michael's posting) that allows more nesting than <topic> allows. - <topic> as a possible direct member of the rich topic - <division> as a nestable organizer (depth zero-or-more) of topics within the rich topic - the ability to connect from <map> to rich topics - the ability to specialize <topic> as before - therefore, the ability (by using a rich topic) to encode a complex topic containing its own background information - a natural separation between the content level (in the rich topic) and the reuse/rearrangement level (in the map)
This preserves the DITA perspective that a topic is a really small chunk, while permitting DITA to be used to encode larger chunks.
To support this fully would mean agreeing to a policy that requires parallel support for topics and rich topics. If a facility would make sense with both, then it should be defined for both.
-----Original Message----- From: Michael Priestley [mailto:mpri...@ca.ibm.com] Sent: Monday, November 07, 2005 11:24 AM To: Paul Prescod Cc: di...@lists.oasis-open.org Subject: Re: [dita] Two proposals for nested sections
Paul, Another alternative is to create an additional base type at the same level as topic that allows nested divisions. That way we don't affect the integrity of the topic architecture, but we give you the ability to design content with nested subheadings within the overall DITA architecture. I'm thinking this would be conceptually something like an article or whitepaper - longer than a topic, may contain topics, but not in itself a topic. Note that we have been authoring articles in DITA just using nested topics (there are examples in the toolkit), and that will continue to be valid as well. So: <article id="xyz"> <title>A longer piece of content</title> <shortdesc>We still have the same general DITA structure of a title, shortdesc, and body</shortdesc> <articlebody> <p>But we have one very important difference: instead of sections, we have divisions, and we allow them to nest.</p> <division> <title>Divisions</title> <p>Divisions have a minimal structure consisting of an optional title followed by block-level content. They are not addressable directly by maps in the way articles or topics are, so in that respect they are more like sections, except that they nest.</p> <topic id="abc"> <title>Topics</title> <body> <p>We also allow topics to be authored inside the body of the article, or pulled in via conref, so that articles can still contain and reuse topics. So articles can still consume topics, even though topics (being smaller) cannot consume articles.</p> </body> </topic> </division> </articlebody> <related-links><link href="somewhereelse.dita"/></related-links> <article id="nestedarticle"> <title>A subarticle</title> <shortdesc>We could even allow articles to nest, after the body - keeping articles separate from articles in the same way we keep topics separate from topics, that is by separating their content into different bodies.</shortdesc> <articlebody><p>And so on...</p></articlebody> </article> </article>
Michael Priestley IBM DITA Architect SWG Classification Schema PDT Lead mpri...@ca.ibm.com
Since your concern is preventing arbitrary nesting of narrative documents, two solutions present themselves:
1. Limit the nesting levels to some agreeable level that is "enough levels" to satisfy most customers wanting grouping and "not so many levels" as to support arbitrary narrative. This is truly a compromise in the sense that neither party walks away comfortable that their concerns are addressed in the general case. This can be easily achieved in a DTD with e.g. "subsection" and "subsubsection" elements.
2. Limit the nesting in the out-of-box DITA using formally declared constraints or prose. In addition, provide a mechanism whereby a knowledgable specializer can loosen the constraint for their specialization (not, typically, to allow indefinite nesting, but rather to allow the creation of grouping elements in the specialization). The specification can outline the dangers of this loosening and the situations under which we believe it is a good thing. If we can agree that these specializers are (in general) knowledgable and trustworthy then both parties achieve their goal.