Proposal 13007: New values for @toc attribute

[Robert D Anderson <robander@us.ibm.com>]

Call for assistance coming...

This item is very low priority for me - I think I offered to look at it
because it seemed trivial, but even trivial items are difficult to fit in
right now.

Specifically, I believe that this was related to cascading values.
Currently, there is an expectation that setting toc="no" will cascade down
until it hits a topicref with toc="yes" -- effectively causing items in
that lower topicref to float up in the TOC. Likewise, toc="yes" will
cascade until it hits toc="no", without a way to override that lower
setting; this can be troublesome if referencing a nested map, such as the
following:
<topicref href="parent" toc="yes">
  <topicref href="nested.ditamap" format="ditamap"/>
</topicref>

where nested.ditamap contains
<map>
  <topicref toc="no">...

In that case, there is no way for the outer map to force the TOC on in the
reused map.

The suggestion was to add values beyond yes/no for @toc, such as "always"
or "never", which forcibly override the values specified further down in
the cascade.

Is anybody else on the TC interested in helping out with a write-up of this
proposal? I'd still like to be involved in the review, but hoping for help
on the other bits.

The record we have of 13007 also suggests that the spec should explicitly
address how the yes/no values cascade, something that today is not
explicitly laid out in the spec (although I think the behavior is defined
as part of a general cascade definition). I think the stage 2 proposal will
probably need to address this explicit behavior, because it is so closely
intertwined with the always/never values; actual language for all of these
cascades would be needed in the stage 3 proposal.

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)