OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: revised chunking proposal



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]