| | 121 | Oddrun: I agree with the proposed solution as far as it goes, and also like that both successor and derived-from are to be introduced. Some questions/issues: |
| | 122 | * Only owners may declare a component deprecated, does that mean that only owners may create a successor/new version? Should the owner be obligated to create a successor to a deprecated component? This makes sense at least if the deprecated component is used in other components/profiles. |
| | 123 | * Propagation of status change: In the proposed solution, steps are taken to prevent inadvertent use of deprecated components (remove them from public view). However, CMDI is a recursive universe, and any component may occur in other components and/or profiles. Consider the following figure: |
| | 124 | |
| | 125 | [[Image(version-propagation.png,600)]] |
| | 126 | |
| | 127 | When C2 is deprecated and a new version is available, this information should in some way be propagated to all its containing components and profiles. If not, both C1 and P1 will remain available in public. Any users selecting P1 (or another profile containing C2) for their metadata will then also choose the deprecated C2, without knowing that it is so. I really think that when a component is "replaced" by a new version, any "new" use of the old version should be strongly discouraged. |
| | 128 | * Information about status change to existing component users: It might be nice to have some kind of subscription service, by which metadata creators, when choosing profiles for their metadata, get the opportunity to subscribe to notification whenever the profile or any of its components change status. |
