The following chunk values will be recognized:
policies (set chunking behavior for the whole map
by setting on the map element):
by-topic, by-document
selection (select content from within a multi-topic document to break out
or include in a new chunk):
select-topic,
select-branch, select-document
output (select whether to create a new chunk of content, or a new chunk
of navigation):
to-content, to-navigation
Other values addable by implementers, who are requested to use values scoped
with a : to differentiate from current and future standardized values.
Here's an example:
Given mydoc.dita:
<dita>
<topic id="A"/>
<topic id="B">
<topic id="B1">
<topic id="B1a"/>
</topic>
<topic id="B2"/>
</topic>
<topic id="C">
<topic id="C1"/>
</topic>
</dita>
map1.ditamap:
<topicref href="a.dita" chunk="to-content">
<topicref href="mydoc.dita#B1" chunk="select-topic"/>
</topicref>
produces a.dita with topic B nested in it
map2.ditamap:
<topicref href="a.dita" chunk="to-content">
<topicref href="mydoc.dita#B1 chunk="select-branch"/>
</topicref>
produces a.dita with topic B nested, and B1 further nested.
map3.ditamap:
<topicref href="a.dita" chunk="to-content">
<topicref href="mydoc.dita#B1 chunk="select-document"/>
</topicref>
produces a.dita with A,B,C nested, and their children subnested. But B1
would get some special treatment, like appearing in the nav in online output.
Note that the whole set of select-x values are only useful when addressing
a subtopic of a nested topic structure - ie, in what for many users will
be a pretty rare edge case.
>
> - I'd still like to see a clearer description/example of
> chunk="navigation" that is neutral with respect to output
formats,
> primarily to see whether "navigation" is itself a set of
related
> values ("navigation-navref", "navigation-pdf",
"navigation-
> flowchart", ...) that certain transformations know how to handle.
On the chunk="to-navigation" front, I think having a general
value is still useful, even if we end up having additional variations on
a media-specific basis. For example, using this to create deeper links
in container-topic summaries would immediately be useful in all our current
HTML-based outputs, including the various help and infocenter formats.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25