| | 27 | |
| | 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. |
| | 30 | |
| | 31 | ==== Status header ==== |
| | 32 | {{{ |
| | 33 | /CMD_ComponentSpec/Header/Status |
| | 34 | }}} |
| | 35 | This mandatory element indicates the status of the component at time of retrieval. It has exactly ''one'' value out of the following: |
| | 36 | * ''development'' (may still be edited by owner(s); only listed if marked for review) |
| | 37 | * ''production'' (should be listed publicly, read-only to everyone) |
| | 38 | * ''deprecated'' (no longer in public listing, queryable and read-only to everyone) |
| | 39 | |
| | 40 | '''Implications for the infrastructure:''' Only the following status changed should be allowed: ''development'' → ''production'' and ''production'' → ''deprecated''. |
| | 41 | |
| | 42 | ==== Status comment header (optional) ==== |
| | 43 | |
| | 44 | {{{ |
| | 45 | /CMD_ComponentSpec/Header/StatusComment |
| | 46 | }}} |
| | 47 | |
| | 48 | This optional element offers a place for the owner of the component to store information regarding the reason for deprecation or succession. |
| | 49 | |
| | 50 | ==== Successor header (optional) ==== |
| | 51 | |
| | 52 | {{{ |
| | 53 | /CMD_ComponentSpec/Header/Successor |
| | 54 | }}} |
| | 55 | |
| | 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. |
| | 58 | |
| | 59 | '''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. |
| | 60 | |
| | 61 | |
| | 62 | ==== Derived from header (optional) ==== |
| | 63 | |
| | 64 | {{{ |
| | 65 | /CMD_ComponentSpec/Header/DerivedFrom |
| | 66 | }}} |
| | 67 | |
| | 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. |
| | 69 | |
| | 70 | Note that the derived-from relation is '''not''' the inverse of the successor relation. |
| | 71 | |
| | 72 | ---- |
| | 73 | |
| | 74 | ==== Infrastructure: Component Registry ==== |
| | 75 | |
| | 76 | ====== Status filtering ====== |
| | 77 | |
| | 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: |
| | 79 | |
| | 80 | * development components marked for review |
| | 81 | * deprecated components |
| | 82 | |
| | 83 | ====== Usage warnings ====== |
| | 84 | |
| | 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) |
| | 89 | |
| | 90 | ====== Automatic 'derived from' ====== |
| | 91 | |
| | 92 | When 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!). |
| | 93 | |
| | 94 | ====== Owner/user notifications ====== |
| | 95 | The following automatic notifications would be nice to have: |
| | 96 | |
| | 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 |
| | 100 | |
| | 101 | RSS and e-mail can be used as means of notification/subscription. |
| | 102 | ---- |
| | 103 | ==== Tools: metadata editing ==== |
| | 104 | |
| | 105 | Deprecated versions of profiles should not be advertised to the user (e.g. should not appear in the profiles list in Arbil) but there should be no restriction in using them (i.e. the can still be added by their schema URL) and existing metadata will be untouched. The metadata editor however could indicate the deprecated status of used profiles, including (non-obtrusive) notifications about the status of the profile the metadata being worked on is based on. For example, the icon shown for the metadata documents could reflect the state of the profile. Similarly, the list of active profiles in Arbil could mark those profiles in the list that are marked as deprecated. In case a successor is available, the editor should notify the user about that as well and ideally offer to load that profile instead (or in addition). Automatic upgrading to the new version should '''not''' happen, but assisting the user in attempting a migration could be considered (here the user should be warned about potential implications on the semantics of the existing values as a result!). |
| | 106 | ---- |
| | 107 | ==== Tools: search & catalogue tools ==== |
| | 108 | |
| | 109 | 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 could make sense to show the status of the profile (e.g. under development, deprecated) if this is considered to be of interest to the user. |
