This page is a subpage of CMDI 1.2
Lifecycle Management in CMDI 1.2: Executive summary
This page provides an executive summary of the issue and proposed solution fully described in CMDI 1.2/Lifecycle management.
Issue description
There is a need for options for versioning and deprecation of CMDI component and profiles. Such features are believed to be helpful in reducing the perceived 'proliferation' in the Component Registry. Currently, published components cannot be deleted without potentially affecting instances and no formal relations between successors and predecessors can be defined.
Description of proposed solution
The component specification needs to be extended with a number of header elements that contain the versioning information, as described in the following subsections.
The CMDI Component Registry will have to manage the status of each component and discourage users (both metadata modelers and creators) from using components or profiles that carry a non-production (i.e. development or deprecated) state. Details of the required changes are given below.
CMDI Component Specification
Status header (mandatory)
/CMD_ComponentSpec/Header/Status
This element indicates the status of the component at the time of retrieval. It has exactly one value out of the following:
- development (may still be edited by owner(s); only listed if marked for review)
- production (should be listed publicly, read-only to everyone)
- deprecated (no longer in public listing, queryable and read-only to everyone)
Implications for the infrastructure: Only the following status changes are allowed: development → production and production → deprecated.
Status comment header (optional)
/CMD_ComponentSpec/Header/StatusComment
This element allows for information regarding the reason for deprecation or succession.
Successor header (optional)
/CMD_ComponentSpec/Header/Successor
This element points to the direct successor of the component, indicating a succession relation. It is only meaningful if the status is deprecated. The value should be the full URI of the successor component. Only a single successor can be specified.
Implications for the infrastructure: Succession is a transitive relation. The status of the final component in a successor chain should be production. Users should be warned when deprecating a component without specifying a successor component.
'Derived from' header (optional)
/CMD_ComponentSpec/Header/DerivedFrom
This element points to the component from which the specified component was derived. No structural relation or similarity is implied. It is intended to be used for the construction of 'derivation trees' to the benefit of metadata modelers. Only a single component can be specified here.
Note that the derived-from relation is not the inverse of the successor relation.
Infrastructure: Component Registry
Inclusion of deprecated components in listings of publicly visible components and profiles should be toggleable (off by default). Warnings can be given, both in component listings (non-obtrusive) and when a user make a life-cycle status change or tries to utilize a deprecated component (dialogue) The DerivedFrom header value should automatically be populated with the ID of the original component if it is 'edited as new'. The user should be able to override this behavior.
It is desirable to offer a means of active notification (by e-mail or RSS) to the user when one or more of their components is affected by a life-cycle status change in another component.
Tools
Metadata editors
Deprecated versions of profiles should not be advertised to the user but there should be no restriction in using them. The metadata editor can indicate the deprecated status of used profiles, and issue (non-obtrusive) notifications about the status of used profiles. In case a successor is available, the editor should notify the user. Existing metadata instance should remain untouched.
Search & catalogue tools
Search tools that explicitly distinguish between profiles in the user interface could apply clustering with respect to different versions of the same profile (traversing the succession chain). In those cases where profile names are shown, it can be considered to show the status of the profile.
