Changes between Version 15 and Version 16 of CMDI 1.2/Lifecycle management

Timestamp:

01/20/14 14:47:22 (10 years ago)

Author:

oddrun.ohren@nb.no

Comment:

--

CMDI 1.2/Lifecycle management

@@ -129 +129 @@
  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.
 
-Oddrun: But in "conflict-of-interest" cases you mention, in which a component successor represents an adaptation in response to some ''particular needs of the owner'', then the deprecated one should NOT be removed from public view. Just as the owner of the existing  C1 might want to go on using the (deprecated) C2, the creator of a ''new component'' might prefer C2 instead of its successor C4 as sub-component. (In this case it would probably be better not to deprecate C2, in stead just generate a new C4 based on C2 using the ''derived-from'' relationship. However, this will be entirely up to the component owners, and can at most be ''guided'' by best practice descriptions). All in all, the most logical outcome of your reasoning is I think to keep all deprecated components selectable from the public list,  - and, whenever a deprecated component is selected for inclusion in a profile, inform the user about the successor. 
+ Oddrun: But in "conflict-of-interest" cases you mention, in which a component successor represents an adaptation in response to some ''particular needs of the owner'', then the deprecated one should NOT be removed from public view. Just as the owner of the existing  C1 might want to go on using the (deprecated) C2, the creator of a ''new component'' might prefer C2 instead of its successor C4 as sub-component. (In this case it would probably be better not to deprecate C2, in stead just generate a new C4 based on C2 using the ''derived-from'' relationship. However, this will be entirely up to the component owners, and can at most be ''guided'' by best practice descriptions). All in all, the most logical outcome of your reasoning is I think to keep all deprecated components selectable from the public list,  - and, whenever a deprecated component is selected for inclusion in a profile, inform the user about the successor. 
 
 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.
@@ -136 +136 @@
 
 ----
- 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.
+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.