Changes between Version 10 and Version 11 of CMDI 1.2/Lifecycle management

Timestamp:

01/16/14 13:53:44 (10 years ago)

Author:

mwindhouwer

Comment:

--

CMDI 1.2/Lifecycle management

@@ -121 +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: 
 * 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.
+ * Menzo: Anyone (including the owner) can create a copy of a component, so at the moment of deprecation or later the owner can pick one of the copies (or even copies of the copies) of them as the successor. But he may also choose to select no successor in which case the component is end-of-life (for him). In problematic cases it will always be possible for the CR admin/content manager to pick a successor.
 * 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:
 
@@ -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.
+ * Menzo: This cascade could easily lead to lot of 'suddenly' problematic components and profiles if a frequently used component is deprecated, e.g., deprecation of cmd-language would cause a large ripple. I think its better to asses the lifecycle status per component, i.e., reuse of C1 is still fine even when its reuses the deprecated component C2. This is due to the fact that the owner of C2 can have very specific reasons for deprecation, which are not shared by the owner of C1. These conflicts of interest shouldn't prevent existing nesting from working, hence no cascades. The CR does try to discourage new nesting of deprecated components, but even that should still be possible.
 * 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.
 
 ----
 Oddrun: After having read other parts of this wiki, I begin to think we should distinguish between updates (to a component) that qualify for state change, and those which do not. For instance, adding a documentation file to a component corresponds to updating its ''metadata'', not the component in itself.  Thereby, it has no consequences for its instances.
+ Menzo: This not a CMDI 1.2 issue but could be a nice addition for the CR. Still its tricky to assess what changes have a semantic impact, e.g., the documentation file might state some restrictions that were not explicit before as they can't be expressed by CMDI, e.g., if element A has a value X then optional element B should have a value.
 
 Discuss the topic in general below this point