--- In dita-users@yahoogroups.com, Michael Priestley <mpriestl@c...>
wrote:
> There is a proposal for 1.1 that may address some of the conditional
> selection concerns. It will allow the map, rather than the build
process,
> to be used for selecting or redirecting resources.

That would solve some of our conditional-selection requirements.
Probably not all of them.

There is an issue of scoping of the keys: I might not want
"productresources" to be the same topic for an entire map. Consider
my perennial example of a book with an install-on-Unix chapter and an
install-on-Windows chapter: same topics, but conrefs point to
different places in each chapter.

I'm also not convinced of how well this meshes with the existing
ditaval architecture. Going back to my example, if I need to add a
warning paragraph only on the Unix installation version of a topic, I
have to use ditaval to filter it in/out. Now my final output depends
on both the map having @keys attributes on topicrefs, *and* on the
build process using the right ditaval file, *and* on them both saying
"Unix" or "Windows" consistently at the same time. That's not exactly
an advertisement for re-use of maps.

I'm not certain how well people will like having two completely
different mechanisms for conditional inclusion and conditional
selection, either.

Don't get me wrong - I love proposed feature #40, but I think that its
failing is that it doesn't go far enough. I'd like to see it subsume
everything that ditaval can do, and more. ditaval files are IMHO
nowhere near as elegant as the rest of the DITA architecture, and
wouldn't hurt from undergoing a complete rethink.