| 11 | | 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 admsuinistrators). Robust though this practice may be, it leads to issues when changes in the domain, or simply new insights, need to be incorporated in the component. It is easy to create a new component based on an existing one, extend it and finally make it public. But then one would like to communicate to the users of the component that they should use the new component for new metadata (possibly even convert existing metadata) instead of the old one. However, there are a few problems: |
| 12 | | co |
| | 11 | 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). Robust though this practice may be, it leads to issues when changes in the domain or new insights need to be incorporated in the component. It is easy to create a new component based on an existing one, extend it and finally make it public. But then one would like to communicate to the users of the component that they should use the new component for new metadata (possibly even convert existing metadata) instead of the old one. However, there are a few problems: |
| | 12 | |
| 42 | | * '''development''' (may still be edited by owner(s). Only listed if marked for review) |
| 43 | | * '''production''' (should be listed publicly, read-only to everyone) |
| 44 | | * '''deprecated''' (no longer in public listing, queryable and read-only to everyone) |
| | 42 | * ''development'' (may still be edited by owner(s); only listed if marked for review) |
| | 43 | * ''production'' (should be listed publicly, read-only to everyone) |
| | 44 | * ''deprecated'' (no longer in public listing, queryable and read-only to everyone) |
| | 45 | |
| | 46 | '''Implications for the infrastructure:''' Only the following status changed should be allowed: ''development'' → ''production'' and ''production'' → ''deprecated''. |
| 82 | | 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 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: |
| | 89 | |
| | 90 | 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: |
| 109 | | 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!). |
| | 117 | 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!). |
