<Light Source Control Link> provides control over the active_light_value field of a <Light Source>. This allows the consuming system to turn the <Light Source> on and off at will.

<Light Rendering Properties Control Link> provides control over the active_value and candela_value field values of the target <Light Rendering Properties> instances. This allows the user to control whether the target is 'on' or 'off', and if it's on, how bright it is. In addition, if the user allows the candela_value field to vary, <Light Rendering Properties Control Link> can specify constraints on the upper and lower limits of the candela value, so that there are limits on the maximum and / or minimum brightness. The user is not required to provide control over all 4 fields, however. If any of the link fields is zero, then the corresponding target field is not controlled.

<Sound Instance Control Link> provides control over the active_sound_value field of a <Sound Instance>. This allows the consuming system to turn the <Sound Instance> on and off at will.

A state-related aggregation represents something that can assume multiple states; each branch of the aggregation represents a particular state. The state-related aggregation object itself specifies the state being describe with its state_tag field. The state is one of a special set of EDCS Attributes that are designated as "state applicable". Each branch of the aggregation has a <State Data> link object, specifying the value of the state associated with that branch.

Consider a specific building represented by a <State Related Geometry> instance. The data provider in this example has chosen to model 4 damage states: 0% damaged, 25% damaged, 50% damaged, and 100% damaged (totally destroyed).

state_tag	EAC_GENERAL_DAMAGE_FRACTION
active_state_value	0%

This indicates that the 'default' state of the aggregation is 0% damage, that is, completely undamaged. The branches' <State Data> link objects have the following field values (meanings given in the bottom row).

state_value	0%	25%	50%	100%
meaning	building's OK	some damage	heavy damage	a little pile of rubble

Generally speaking, any state-related aggregation should be produced with an appropriate <State Control Link> component. After all, if a data provider has created an object that can assume one of multiple states, it only seems reasonable to provide the mechanism to change between states; why would a producer go to the trouble of representing multiple states of an object if only the default state could ever be used? Consequently, the building example needs a <State Control Link> to allow the use of states other than the default of 0% damage.

The <State Control Link> component controls the active_state_value by providing a connection between it and the controlling <Expression>, so that the active_state_value changes to specify which branch of the aggregation is currently active. Since active_state_value is the only controlled field in a state-related aggregation, the <State Control Link> should have exactly 1 <Expression> component, and therefore its expr_index field value would be 1.

expr_index	1
mismatch_behaviour	SE_STATE_MSM_BHVR_LAST

In this example, the <Expression> is a <Variable>, so that whatever value is plugged into the <Variable> when the <State Related Geometry> is instanced is then fed into the active_state_value.

meaning	{ SE_ELEM_CODE_TYP_VARIABLE, SE_VAR_CODE_ACTIVE_STATE_VALUE}
value_unit	EUC_UNITLESS
value_scale	ESC_UNI
value_type	SE_PDV_FLOAT
description	{SE_LOCALE_DEFAULT, 12, "damage state"}
runtime_label	{SE_LOCALE_DEFAULT, 0, ""}

Suppose that a value of 25% is supplied to the <Variable>. The aggregate then changes state to 25% damage. Then more damage is done, so that the damage is updated to 45%. This presents a problem, because the data provider has specified each branch with a single matching value, and 45% is not covered by any of the branches. At this point, the mismatch_behaviour of the <State Control Link> comes into play. Since its value is SE_STATE_MSM_BHVR_LAST, the aggregation will remain in the 25% damage state.

There are two other possible choices for mismatch_behaviour, but they are not appropriate for this example. SE_STATE_MSM_BHVR_DEFAULT would have reset the aggregate to its default state (that provided by the original unmodified active_state_value), namely, 0% damage. The effect would be that 45% damage would magically appear to return the building to its intact state, as for that matter, would 99% damage, or any other value not covered by the branches of the aggregation. This would seem rather peculiar to the end user. The other possible choice, SE_STATE_MSM_BHVR_NONE, acts as an 'off' state. The building would seem to disappear completely if none of the branches matched, then reappear when a matching value occurred. If that had been specified, 5% damage would make the building disappear from sight, but 25% damage would make it reappear, making life rather bizarre for the end user.

<CMY Colour Control Link>, <HSV Colour Control Link>, and <RGB Colour Control Link> serve exactly the same purposes for their respective colour models. An understanding of the operation of any of the three is an understanding of the principles underlying the operation of all three. Consequently, this section will describe the operation of <RGB Colour Control Link> only, with the understanding that the explanation applies to the other two classes in principle.

<RGB Colour Control Link> provides control over the red, green, and blue fields of the target <RGB Colour> instances. A data provider is not required to provide control over all three fields. If any of the link fields within an <RGB Colour Control Link> instance is zero, that indicates that the corresponding target field is not controlled.

<RGB Colour> instances within the context of a <Colour Table> shall not have <RGB Colour Control Link> components, because a <Colour Table> does not provide an <Interface Template> to allow values to be supplied for <Variable> instances. Data consumers need only concern themselves with <RGB Colour Control Link> instances in the context of <Model> and <Environment Root> instances, and even in that case primarily with the former rather than the latter.

A data provider may wish to provide control over the colour of a <Model>, so that every <Geometry Model Instance> of that <Model> can be given a different colour, allowing the user of the <Model> to vary the appearance of model instances without being forced to replicate many <Model> instances that differ only in colour. As another example, a <Model> representing a car may be designed for an environment in which thermal colours are a consideration. In this case, the user might need the ability to change the colour of the car dynamically, as the engine heats up from a cold start or as the engine cools down after being shut off.

<Attribute Set Index Control Link> provides control over the index field value of the target <Attribute Set Index> instances. For example, the appearance of a tree canopy varies according to the season of the year, so a data provider may choose to provide the ability to apply different texture maps and colours to a representation of a tree canopy to represent its appearance in different seasons. This can be achieved by providing an <Attribute Set Table> containing a different <Attribute Set> for each season of the year, which in turn specifies appropriate <Colour> and <Image Mapping Function> instances. The aggregate representing the tree canopy is provided with an <Attribute Set Index> with a component <Attribute Set Index Control Link>, to allow the user to change the <Attribute Set Index> index field to select the appropriate <Attribute Set> for a given time of year.

<Colour Index Control Link> provides control over the index and intensity_level fields of the target <Colour Index> instances. A data provider is not required to provide control over both field values. If either of the link fields within a <Colour Index Control Link> instance is zero, that indicates that the corresponding target field is not controlled.

<Property Table Reference Control Link> provides control over the index_on_axis field of the target <Property Table Reference> instances. This allows the user to specify different N-1 dimensional 'slices' of the N-dimensional <Property Table> that is referred to by a given target <Property Table Reference> instance.

For example, consider a <Polygon> instance that specifies the electromagnetic properties of its surface material by a <Property Table Reference> component. If the <Property Table Reference> has a <Property Table Reference Control Link>, its index_on_axis field value can be changed at will, allowing the user to change the electromagnetic properties of the <Polygon> as a result.

<Rotation Control Link> provides control over the angle field values of the target <Rotation> instances. In addition, <Rotation Control Link> is specialized to provide control over the upper limit and / or lower limit of the rotation angle, although a data provider is not required to provide control over all three target fields. If any of the link field values within a <Rotation Control Link> instance is zero, then the corresponding target field value is not controlled.

An example of the use of <Rotation Control Link> is to specify physical constraints on the rotation of a moving part (as well as to allow the part to rotate in the first place). Consider a robot with a jointed 'arm', where the joint acts like a human elbow: the 'forearm' can be rotated for a range of 90 degrees about the axis of the elbow joint, but there are upper and lower limits to the angle of rotation where the joint would have to be broken to permit any further rotation.

An example where rotation might be provided without limits can be provided by considering a weathervane. A weathervane can rotate about its axis, but has no physical limits on its rotation, so it does not have to be modelled with constraints on the amount of rotation.

As an example, consider a <Model> of a rotating weather vane, such that the weather vane turns to match the wind direction. The <Model&;gt; therefore has an <LSR Transformation> on its top-level geometry to represent the rotation - that is, the <LSR Transformation> has a <Rotation> component.

However, the rotation angle is determined by the wind direction, which is not a fixed value, and is not the same at different locations in the world. Each instance of the weather vane needs to have an independent rotation. Consequently, the <Rotation> has a <Rotation Control Link> component that changes the angle value of the <Rotation> to match the wind direction. The controlling <Expression> of the <Rotation Control Link> is therefore a <Variable> with a meaning of ROTATION_ANGLE. This <Variable> is associated by the <Model>'s <Interface Template> so that each instance of the model can plug in the appropriate value, in this case the wind direction at that point.

<Translation Control Link> provides control over the translation_amount field of the target <Translation> instances. Specifically, <Translation Control Link> is specialized to provide control over the amount of translation, together with control over the lower limit of that amount and / or control over the upper limit. A data provider is not required to provide control over all three field values. If any of the link field values within a <Translation Control Link> instance is zero, that indicates that the corresponding target field is not controlled.

An example of the use of a <Translation Control Link> is to specify physical constraints on the motion of a moving part. For instance, a building <Model> may contain an elevator that can move up or down an elevator shaft. The elevator has physical limits on how far it can translate up or down without smashing into the top of the shaft or plunging through the bottom, so it requires upper and lower limits on the amount of translation.

As another example, consider a robot with an 'arm' that can be extended or retracted from its 'body'. The arm has physical limits on how far it can be extended without 'floating' away from the robot's body, and how far it can be retracted into the robot without 'breaking' the model. Consequently, it requires upper and lower limits on the amount of translation.

<Feature ID Control Link> provides control over the ID field of its target <Feature ID> instances, while <Geometry ID Control Link> provides control over the ID field of its target <Geometry ID> instances. These two subclasses of <Control Link> serve the same purpose for different target classes, so that an understanding of either is essentially an understanding of both. Consequently, this discussion focusses on <Feature ID Control Link>, with the understanding that the principles involved apply to both classes.

A <Feature ID> exists to uniquely identify some <Feature Topology> instance within a given SEDRIS transmittal, just as a <Geometry ID> exists to uniquely identify some <Geometry Topology> instance.

Consider a <Feature Node> instance that appears within a <Feature Model>. If the <Feature Node> has a <Feature ID> with a fixed ID value, then every <Feature Model Instance> referring to the <Feature Model> would be using the same ID to refer to that <Feature Node> instance, although each instance of the <Feature Model Instance> is different.

For example, consider a <Model> representing a 'generic' bridge with a <Feature Model>, where the bridge topology consists of a single <Feature Edge>, which has a <Feature ID>. If the <Feature ID< does not have a <Feature ID Control Link>, then every instance of the bridge will attempt to use the same ID value for the bridge's topology. For every instance of the bridge to uniquely identify its topology, a <Feature ID Control Link> driven by a <Variable> is needed.