pure::variants supports a user-specified generation of product variants using an XML-based transformation component. Input to this transformation process is an XML representation of the Variant Result Model. Transformation modules are bound to nodes of the XML document according to a user-specified module configuration. These processing modules encapsulate the actions to be performed on a matching node in the XML document.
A set of generic modules is supplied with pure::variants, e.g. a module for collecting and executing transformation actions. The list of available transformation depends on the pure::variants product and installed extensions.
The user may create custom modules and integrate these using the pure::variants API.
The transformation module configuration is part of the Configuration Space properties (see Section 6.3.1, “ Setting up a Transformation ” ).
The transformation process works by traversing XML document tree. Each node visited during this traversal is checked to see whether any processing modules should be executed on it. If no module has to be executed, then the node is skipped. Otherwise the actions of each module are performed on the node. Further modules executed on the node can process not only the node itself but also the results produced by previously invoked modules.
The processing modules to be executed are defined in a module configuration file. This file lists the applicable modules and includes configuration information for each module such as the types of nodes on which a module is to be invoked. The transformation engine evaluates this configuration information before the transformation process is started.
The transformation engine initializes the available modules before any module is invoked on a node of the XML document tree. This could, for instance, give a database module the opportunity to connect to a database. The transformation engine also informs each module when traversal of the XML document tree is finished. The database module could now disconnect.
Before a module is invoked on a node it is queried as to whether it is ready to run on the node. The module must answer this query referring only on its own internal state.
Part of the SDK is a separately distributed manual contains further information about the XML transformer. This manual shows how the built-in modules are used and how you can create and integrate your own modules.
For each Feature and Family Model of the Configuration Space a concrete variant is calculated during the model evaluation, collected in the so-called Variant Result Model. In full configuration mode, the concrete model variants contain only the selected features and elements. Successfully evaluated restrictions and constraints are removed and attribute value calculations are replaced by their calculated values. In partial configuration mode, the concrete model variants contain both the selected and open features and elements. Only the excluded features and elements are removed. In case of that single calculation results are still open, the concrete model will still contain these calculations. Only the calculations which evaluate in a non-open value will be replaced. Also in case of open restrictions on attribute values, the concrete model variants can contain more attribute values than in full configuration mode.
The type of the feature and family models is changed to signal that these models are concrete variants (see Table 5.1, “Mapping between input and concrete model types” ).
Table 5.1. Mapping between input and concrete model types
| Input Model Type | Concrete Model Type |
|---|---|
| ps:fm (Feature Model) | ps:cfm (Concrete Feature Model) |
| ps:ccfm (Family Model) | ps:ccm (Concrete Family Model) |
| ps:vdm (Variant Description Model) | ps:vdm (Variant Description Model, identical to the input model) |
The Variant Result Model contains additional variant information and is the input of the pure::variants transformation. It has the following structure.
<variant> <locationinfo> <model mid="variant model ID">variant model URL</model> <model mid="feature model ID">feature model URL</model> <model mid="family model ID">family model URL</model> </locationinfo> <cm:consulmodels xmlns:cm="http://www.pure-systems.com/consul/model"> <cm:consulmodel cm:id="variant model ID" cm:type="ps:vdm" cm:version="1.5"> ... </cm:consulmodel> <cm:consulmodel cm:id="feature model ID" cm:type="ps:cfm" cm:version="1.5"> ... </cm:consulmodel> <cm:consulmodel cm:id="family model ID" cm:type="ps:ccm" cm:version="1.5"> ... </cm:consulmodel> </cm:consulmodels> </variant>
The
locationinfo
subtree of this XML structure lists the URLs of
the models used in the stored variant including the variant model. If
the stored Variant
Result Model is used for inout to a evaluation or transformation
pure::variants tries to
open the input models from the stored locations to complete the
variant. The
cm:consulmodels
subtree contains a list of all the concrete
models.
Tip
A copy of this XML structure can be saved using the "Save Result to File" button that is shown in the tool bar of a variant description model or automatically as part of a transformation result. See the section called “Input-Output Page” for more information.