The basic idea of control links is that the abstract class <Control Link> provides a connection between <Expression> trees and the fields of other SEDRIS objects, called target objects. For each class of target object, there shall be a matching, specialized subclass of <Control Link>, the definition of which specifies how it's ordered <Expression> components are used to determine the values of the fields of the target object (called target fields). The target object shall aggregate an instance of the specialized <Control Link>.

In general, a specialized <Control Link> will contain at least one field, called a link field, for each field in the target object. The link field is a 1-based index into the ordered list of <Expression> components, and is used to select the specific <Expression> that controls the value of the target field. The specialization may also contain "constraint" fields that are used to constrain the values of the target field. These constraint fields are indexes into the ordered list of <Expression> components.

<Expression> is an abstract class used to represent places in a transmittal where the consuming system is required to perform an evaluation in order to get the exact value of a target field. An <Expression> tree is composed of other <Expression> trees, nesting to an arbitrary level. Together, the set of <Expression> trees connected to a <Control Link> defines the desired relationship and behaviour of controlling inputs to values, which will be applied to the fields of other SEDRIS objects (called target objects and target fields). The application of <Expression> instances to target fields is defined by a specialization of the <Control Link> class, which associates the values of the <Expression> instances to the fields of the target object(s).

For example, the <State Related Geometry> class has an optional relationship with the <State Control Link> subclass of <Control Link>. This specialization defines which of the <State Control Link>'s ordered <Expression> components are to be applied to the fields of the <State Related Geometry>.

There are 3 subclasses of <Expression>: <Literal>, <Variable>, and <Function>.

A <Literal> is the simplest <Expression>; it is merely a constant value.

A <Variable> is a surrogate for a value that will be supplied by way of an <Interface Template>. <Interface Template> instances, which are aggregated by <Environment Root> and <Model> instances, specify the "hooks" that may be controlled within the parent <Environment Root> or <Model> by the consuming system. An <Interface Template> instance is associated with one or more <Variable> instances. <Geometry Model Instance> and <Feature Model Instance> aggregate <Expression> components, indicating their relationship with the appropriate <Interface Template> (that of the <Model> being instanced).

Essentially, a <Variable> exists to connect an <Interface Template> to points within <Expression> where outside control may be exerted.

For a <Variable> contained within a <Model>, evaluation is valid only for a specific model instance. The value is determined by an <Expression> aggregated by the specific <Feature Model Instance> or <Geometry Model Instance>.

For <Variable> instances contained within an <Environment Root>, evaluation can only be performed within the context of values that shall be supplied by the consuming system.

When the general constraints <<Constraints On Components>> and <<Constraints On Associates>>, some practical consequences arise. Since a <Variable> must be associated by an <Interface Template> to be syntactically valid, and a <Variable> within a <Model> cannot be associated by any <Interface Template> outside that <Model>'s composition tree, it follows that any <Model> containing <Variable> instances must have an <Interface Template> component. Further, a <Model>'s <Interface Template> associates to the <Variable> instances - and only the <Variable> instances - of that particular <Model>. This combination of constraints guarantees that when a model is instanced, the end application can determine for that instance what <Variable> instances must be supplied with values to fully specify the model instance, and that the control system specified by the model's internal <Control Link> instances affects that <Model>, without side effects on unrelated <Model>s.

Another consequence of these constraints is that a <Variable> instance cannot belong to the component tree of more than one <Model>. This is only logical - the rotation of an airplane propeller and that of a ceiling fan are both rotational quantities, but they are not driven by the same control system.

A <Variable> instance cannot be a component of both a <Model> and an <Environment Root>. A <Variable> within a <Model> specifies a controlling variable for that one construct, while an environmental variable expresses a more 'global' quantity, such as prevailing wind direction or air temperature.

Since a <Control Link> always (in practice) uses an <Expression> containing a <Variable>, <Control Link> instances only appear within the context of <Model> and <Environment Root> component trees.

The <Interface Template> component of a <Model> has ordered associations to every <Variable> within that <Model>. This ensures that the end user does not have to search the entire <Model> to find all the <Variable> instances. The mechanism can be described by a lock-and-key analogy. An <Interface Template> defines the 'lock' - all the <Variable> instances that must be supplied with values when the <Model> is instanced in a playbox. Each model instance must supply its own 'key' - a set of <Expression> instances to be plugged into that set of &<Variable>s.

In practice, every <Control Link>; instance either has a <Variable> as its controlling <Expression>, or a <Function> that is in turn controlled by a <Variable>. If the <Control Link> value could never change state, then the target fields' values would be fixed, and there would be no need for a controlling <Expression> to be present.