Variant criteria are assigned to topics and any other objects you want to "swap out" for the different "flavors" of your documentation. The variant criteria are used by the book filter and the publishing filter.
Your Security Administrator creates variant criteria using the variable options. However, once you select the option to convert the variable to a variant criteria, you unlock specific functionality. Variant criteria differ from variables because the values are assigned to objects as metadata rather than being used in the topic content.
Variant criteria are created using the List of Values option. The structure applied to the values defines how objects are swapped out. Let's look at two examples, the flat structure and the "stepped" fall-back structure.
|
Flat structure |
Fall-back structure |
|
|
|
Flat structure
The flat structure (the image on the left) is used when you want to use a variant, or if there is no variant you want to use the primary object. Think of this as a "black or white" option - if the selected variant exists then it is used, if there is no matching variant then the primary object is used.
In this example the primary object is the X1000 version of the documentation. If the content is filtered for the X6000 and a topic for the X6000 does not exist, the topic for the X1000 will be used instead.
Software releases: Fall-back structure
The fall-back structure (the image on the right) is used when you want multiple "shades of gray" of the primary object. With this stepped structure, if a specific variant does not exist, you can fall-back to another variant option.
The fall-back structure is ideal for working with software releases. If you have created a variant topic for a specific release then that variant is used, otherwise a variant from the previous release can be used.
In this example the content can be filtered for release 2.0. If a variant topic does not exist for release 2.0 then the variant for release 1.2 will be used; if a variant for release 1.2 doesn't exist then the variant for release 1.1 will be used, and so on.
Software releases: Branched fall-back structure
The fall-back structure can also include branching. In this example release 1.1 includes a branched fall-back path for release 1.1b.
Variant content that is unique to release 1.1b can be created using the normal methods. Because this value is branched from the release for 1.1, instead of being added to the main path, any content for release 1.1b will not be included when content for the 1.2 release is published. (The fall-back path from release 1.2 goes directly to release 1.1, then to release 1.0.)