Changes between Version 17 and Version 18 of CMDI 1.2/Lifecycle management


Ignore:
Timestamp:
02/11/14 15:59:55 (10 years ago)
Author:
twagoo
Comment:

discussion outcome summary

Legend:

Unmodified
Added
Removed
Modified

  • CMDI 1.2/Lifecycle management

    v17 v18  
    1010
    1111Once 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 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 
     12co
    1313* There is no reliable way to find out who is instantiating specific components, so the users are unknown and cannot simply be informed
    1414* The old component cannot be deleted, so new users might accidentally start using the old one
    … …  
    141141 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.
    142142
     143----
     144
     145Summary of conclusions from WG e-mail discussions (2014-2-10):
     146
     147* Model aspects (component specification header) are settled
     148* Only owner (and CR administrator) can change the lifecycle status of a component in the registry
     149 * But anyone can make a derivative of any component
     150* Lifecycle status should not propagate to referencing components (i.e. component X that includes component Y does ''not'' change status when component Y becomes deprecated)
     151* Modellers should be discouraged from using deprecated components but not disallowed. Default filtering should hide deprecated and development components in the registry
     152* Metadata creators should be discouraged from instantiating deprecated profiles by similar means
     153
     154
    143155Discuss the topic in general below this point