Changes between Version 3 and Version 4 of CMDI 1.2/Lifecycle management/Summary


Ignore:
Timestamp:
03/05/14 14:55:32 (10 years ago)
Author:
Twan Goosen
Comment:

further condensed summary

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Lifecycle management/Summary

    v3 v4  
    77== Issue description ==
    88
    9 Once published, a component gets 'frozen' so that all instantiations can rely on it not changing and thus are guaranteed to retain their validity. Also, after a certain 'cooling down' period, published components cannot be removed from the public space (except by administrators). This leads to issues when changes in the domain or new insights need to be incorporated in the component.
    10 One can create a new component based on an existing one, extend it and finally make it public. But as a versioning mechanism this has a number of limitations:
    11 
    12 * There is no reliable way to find out who is instantiating specific components, so the users are unknown and cannot simply be informed
    13 * The old component cannot be deleted, so new users might accidentally start using the old one
    14 * All of this is very informal, and requires a lot of work with few guarantees
    15 
    16 A formal way of deprecating components and specifying versioning information would solve these issues. In such a '''workflow''', the owner of a component can:
    17 
    18 0. Create a new component (e.g. by copying the existing component as a basis)
    19 0. Edit until satisfied
    20 0. Publish into public space
    21 0. Deprecate the 'precursor' component
    22 0. Designate the new component as 'successor' to the old one
    23 
    24 This information needs to be communicated to the client that request the deprecated component, and remove it from the public list. Clients should of course still be able to use the deprecated component since it is not always possible to upgrade.
     9There 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 potential affecting instances and no formal relations between successors and predecessors can be defined.
    2510
    2611== Description of proposed solution ==
    2712
    28 The '''component specification''' needs to be extended with a number of header elements that contain the versioning information. The header elements to be added are described in the following subsections.
    29 In addition to these extensions to the component model, the ''infrastructure'' needs to be adapted to implement a ''workflow'' for changing lifecycle statuses and the consequences of such changes. More specifically, the CMDI Component Registry will have to manage the status of each component and discourage users (both metadata modellers 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.
     13The '''component specification''' needs to be extended with a number of header elements that contain the versioning information, as described in the following subsections.
     14The CMDI Component Registry will have to manage the status of each component and discourage users (both metadata modellers 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.
    3015
    3116==== Status header ====
    … …  
    4631}}}
    4732
    48 This optional element offers a place for the owner of the component to store information regarding the reason for deprecation or succession.
     33Optional element allowing for information regarding the reason for deprecation or succession.
    4934
    5035==== Successor header (optional) ====
    … …  
    5439}}}
    5540
    56 This optional element points to the direct successor of the component. It indicates a succession relation and is only meaningful if the values of ''/CMD_ComponentSpec/Header/Status'' is ''deprecated''.
    57 The value should be the full URI of the successor component. Only a single successor can be specified. The successor relation thus is a 1:1 relation.
     41Optional element pointing to the direct successor of the component, indicating a succession relation. It is only meaningful if the status is ''deprecated''.
     42The value should be the full URI of the successor component. Only a single successor can be specified.
    5843
    5944'''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.
    6045
    61 
    62 ==== Derived from header (optional) ====
     46==== 'Derived from' header (optional) ====
    6347
    6448{{{
    … …  
    6650}}}
    6751
    68 This optional element points to the component from which the specified component was derived. This information gets stored at the moment a component is created (i.e. generally this will happen automatically in the Component Registry). No structural inheritance or even similarity is implied. This element is intended to be used for the construction of 'derivation trees' for metadata modelers to navigate, e.g. inside the Component Registry. Only a single component can be specified here.
     52Optional element pointing 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.
    6953
    7054Note that the derived-from relation is '''not''' the inverse of the successor relation.
    … …  
    7660====== Status filtering ======
    7761
    78 The browsing mode of the Component Registry, as well as the REST service through which the list of components and profiles can be requested, needs to be filterable. Currently, there is a switch between private and public components. With the proposed set of status values, this needs to be revisited. A suitable paradigm seems to consist of two main views: components visible by the logged in user and components visible to the public; there may be an overlap. Then the following filter toggles are available for the latter view, both OFF by default:
     62The browsing mode of the Component Registry and its component listing in the REST service need to be filterable. The currently present switch between private and public components needs to be replaced with two new main views: one for components visible by the logged in user and one for components visible to the public; there may be an overlap. Then the following filter toggles are available for the latter view, both OFF by default:
    7963
    8064* development components marked for review
    … …  
    8367====== Usage warnings ======
    8468
    85 The default filter settings described above are the first and most important step in discouraging users to use non-production components. In addition, warnings can be given at two stages:
    86 * visually but non-obtrusive in the listing (e.g. warning icons on rows that represents the deprecated or development components)
    87 * through a modal dialogue when a user actively decides to include such a component (through 'edit as new' or by dragging it into a component being edited). Should be checked recursively, i.e. also give warning whenever the the selected component '''contains''' deprecated components.
    88 * visually in single component view (e.g. warning icon (same as in listing) beside any deprecated sub-components in the lower pane of CR)
     69Warnings can be given at different stages:
     70* visually but non-obtrusive in the listing (e.g. warning icons in the table)
     71* through a modal dialogue when a user actively decides to include such a component (recursively).
     72* visually in single component view (e.g. warning icon beside any deprecated item)
    8973
    9074====== Automatic 'derived from' ======
    … …  
    9377
    9478====== Owner/user notifications ======
    95 The following automatic notifications would be nice to have:
     79It would be desirable to offer a means of active notification to the user in a number of cases:
    9680
    97 * Notification of component owners when a component referenced (either directly or indirectly) in one of their components becomes deprecated
    98 * Notification of component owners when a derivative of one of their components is created
    99 * Notification of component subscribers when any of the subscribed components become deprecated
     81* to component owners when a component referenced (either directly or indirectly) in one of their components becomes deprecated
     82* to component owners when a derivative of one of their components is created
     83* to subscribers when any of the subscribed components become deprecated
    10084
    10185RSS and e-mail can be used as means of notification/subscription.