Conditional keys

Give a key several definitions with different conditions, and each reader gets the first definition their filter keeps, which is DITA's rule applied per reader.

These docs define who to ask for help twice:

<keydef keys="help-contact" product="hosted">
  <topicmeta><keywords><keyword>the operator of your docs site</keyword></keywords></topicmeta>
</keydef>
<keydef keys="help-contact">
  <topicmeta><keywords><keyword>the OpenD maintainers on GitHub</keyword></keywords></topicmeta>
</keydef>

A topic writes <ph keyref="help-contact"/>. For you, right now, that reads: ask the operator of your docs site.

How it works

A static DITA build picks one definition per output. OpenD builds once for every reader, so it keeps all the definitions, in precedence order, as alternatives in the release snapshot. When a page is served, the reader's filter removes the alternatives they don't qualify for and keeps the first that remains.

Put the most specific definition first and an unconditional one last, as a default. Definitions after an unconditional one can never win.
If no definition survives for a reader, the element's own content is used, as for an undefined key.
Conditions on the map entries around a keydef count as its conditions.
The build-time DITAVAL does not choose between alternatives, because it runs for every reader at once. It only removes definitions it excludes.
In the previewer's staff view, every alternative is shown, separated by a bar and marked with its conditions.

Conditional keys work for variable text, links and images, and for conkeyref, so a reader can get a different reusable chunk.