Purpose

The represents dependencies between different release . In each case, the dependency indicates which of each particular a given of the dependent requires.

Data structure

The  is a - which is used to represent dependencies between , taking account of versioning. Its structure is shown in the following table.

Rules and Guidance

Introduction to Modules

Each row in the release files for components and reference set members has a . This refers to the  that the component is maintained in. Each module is either part of the  or part of a single  . The  has a  which indicates whether it is part of the  and, if not, its  indicates the  that it belongs to.

A module is simply a collection of  maintained as a unit by a single organization. It is the organization 's responsibility to organize the components in each  that it is responsible for into one or more modules, in a way that best fits its business needs.

A module is represented by a  of  in the metadata . The immediate subtype descendants of  represent groups of modules maintained by an organization and subtypes of these can be used to arrange that organizations modules into a number of groups. For example, all modules maintained by  will be  of .

At any point in time a  must be in one, and only one module. It is possible for components and reference set members to be moved between modules (subject to constraints explained elsewhere). In this case, a new row is added to the release file with the same  but with a new  and a new . 

Introduction to Module Dependencies

Each  must include one or more modules. Each module must be part of either the  or one and only one .  A module may not move from one  to another over time. If components or reference set members in a module are to be moved from an  to the  or to another , they must either be added to an existing or newly created module maintained by the destination organization.

The   does NOT represent dependencies between module. Instead, module dependencies are modeled using the  .

At the point of release, if any  within a module has changed, then a new row must be added to the  for each dependency of that module. The  of the added rows must set to the date of the new release. The updated  records indicate that some components within the module have been updated in this release. If there have been no additions, updates or inactivations of components or reference set members within a module, then a new  records need not be added unless there is a requirement to declare that the unchanged module is compatible with a later release of the module(s) on which it dependents.

Identifying and Versioning Module Dependencies

id

The recommended practice is for the refset.id column to contain the same identifier for all versions of the dependencies between the same pair of modules. This approach means that at any given time only one version of each module has effective dependencies. The dependencies of earlier versions can be reviewed by reviewing a snapshot for the effectiveTime of the earlier release.

effectiveTime

The effectiveTime of at least one row for each pair of modules should be the same as the sourceEffectiveTime. Otherwise, there will be a period of time when a snapshot view will not show the dependencies. However, it is theoretically possible for an additional row to be added with a later effectiveTime in cases where an otherwise unchanged release of an extension, declares itself to be compatible with an updated release of the target module (in this case the effectiveTime and targetEffectiveTime are changed but the sourceEffectiveTime remains unchanged.

active

A module dependency only needs to be inactivated if the dependency is found to be erroneous. This is because, the module dependency is specific to a particular version of the source and target module. Therefore, if that dependency was valid at the outset it remains valid indefinitely in respect of those specified module versions, even if the dependencies between subsequent versions differ.

refsetId

Module version dependencies are represented using a single . Thus all module dependency rows have the same refsetId ().

It is the responsibility of the organization owning and maintaining a dependent module to identify all modules on which it depends. They do this by adding rows to the within the dependent module. Because these added member must be in the dependent module, the of the member record is also the identifier of the dependent (source) module.

Module Identification

Source Module  (moduleId)

The  column not only indicates that this reference set member is in the specified module, it also indicates that this is the module that is the source of the dependency. As a result, in this reference set the  column is immutable (i.e Mutable=NO). This is an exception to the usual rule and implies that a member of this reference set cannot move from one module to another.

Target Module (referencedComponentId)

The target module on which the source module depends is identified by the . Like the source module this is also immutable and this implies that if a module ceases to be dependent on another module, a new row inactivating the dependency can be added but the same member cannot be used to represent a different dependency (even if that dependency is a direct replacement of the inactivated dependency). However as noted above, 

A module version may depend on one or more other module versions, and many module versions may have a dependency on a single module version. Cyclic module version dependencies are not allowed. If module-A depends on module-B, then module-B cannot depend on module-A.

Dependencies are not transitive and this means that dependencies cannot be inferred from a chain of dependencies. If module-A depends on module-B and module-B depends on module-C, the dependency of module-A on module-C must still be stated explicitly.

Any release should consist of a set of module versions that are certified as being compatible. Each release should also identify other module versions that it is dependent on even when these are outside the scope of the release. For example, the dependencies of modules in an Extension on the International Release must be stated.

Dependencies are specified between module versions, not just dependencies between modules. Therefore, it is possible to specify a dependency from a module released on one date to an earlier version of another module. The version of the dependent module is specified by the and the version of the module on which it depends is specified by the .

Metadata

The following metadata in the "Foundation metadata " supports this :

  900000000000454005 |Foundation metadata concept|
		900000000000455006|Reference set|
				900000000000534007 |Module dependency|

Descriptor

The table below shows the descriptor that defines the structure of the .

Note: The table above omits the initial four columns of data present in the release file. These follow the standards versioning pattern , , , . Additionally, to aid understanding, the table above also shows the from one of the associated with each of the identified . The release file only contains the .

Example Data

Example The table below holds example entries for the in a of the January 2014 .

This contains three modules:

• which has no dependencies;
• which depends on the ; and
• which depends on both the other modules.

In this case all the 2014-01-31 modules depend on 2014-01-31 versions of the other modules. However, in some case a module may depend on an earlier version of another model (e.g. an extension module may be releases after the to which it applies).

Dependencies are not transitive. The fact that is dependent on may seem to imply a dependency on . However, in practice all dependencies must be explicitly specified, not just immediate dependencies.