| 62 | | The 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: |
| 63 | | |
| 64 | | * development components marked for review |
| 65 | | * deprecated components |
| 66 | | |
| 67 | | ====== Usage warnings ====== |
| 68 | | |
| 69 | | Warnings 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) |
| 73 | | |
| 74 | | ====== Automatic 'derived from' ====== |
| 75 | | |
| 76 | | 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!). |
| 77 | | |
| 78 | | ====== Owner/user notifications ====== |
| 79 | | It would be desirable to offer a means of active notification to the user in a number of cases: |
| 80 | | |
| 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 |
| 84 | | |
| 85 | | RSS and e-mail can be used as means of notification/subscription. |
| 86 | | ---- |
| 89 | | 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!). |
| 90 | | ---- |
| | 66 | Deprecated versions of profiles should not be advertised to the user but there should be no restriction in using them. |
| | 67 | The metadata editor can indicate the deprecated status of used profiles, and issue (non-obtrusive) notifications about the status of used profiles. |
| | 68 | In case a successor is available, the editor should notify the user. Existing metadata instance should remain untouched. |
| | 69 | |
