Changes between Version 19 and Version 20 of CMDI 1.2/Lifecycle management


Ignore:
Timestamp:
02/11/14 16:24:46 (10 years ago)
Author:
twagoo
Comment:

extended component registry section

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Lifecycle management

    v19 v20  
    6969This 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.
    7070
    71 ==== Pros ====
    72 
    73 Pros of this solution
    74 
    75 ==== Cons ====
    76 
    77 Cons of this solution
    78 
    7971==== Centre impact ====
    8072
    … …  
    8577Status can be mapped to views, see [[ComponentVersioning#Viewsworkspacesandregistries|ComponentVersioning]]. Besides that, the Component Registry will have to provide inputs for the user to manage the status of their own components. Part of the information gathering can be automated (!DerivedFrom).
    8678
    87 ====== Nice to haves ======
     79'''Status filtering'''
     80The browsing mode of the Component Registry, as well as the REST service through which the list of components and profiles can be requested, needs te 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:
    8881
     82* development components marked for review
     83* deprecated components
     84
     85'''Usage warnings'''
     86
     87The 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:
     88* visually but non-obtrusive in the listing (e.g. warning icons on rows that represents the deprecated or development components)
     89* 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)
     90
     91'''Automatic 'derived from''''
     92
     93When a component is created by selecting an existing component and clicking 'edit as new', the !DerivedFrom header value should automatically be populated with the ID of the original component. However it should be possible for the user to remove this or put another ID in place (but this should clearly be an advanced option!).
     94
     95'''Nice to haves'''
    8996* Notification of component owners when a component referenced in one of their components becomes deprecated
    9097* Notification of component owners when a derivative of one of their components is created