Issues for MOF 2.0 Versioning Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 8999: Sections 5.3 and 5.5
Issue 9021: Section: section 5.5

Issue 8999: Sections 5.3 and 5.5 (mof2versioning-ftf)

The "MOF2.0 Core Specification" states that a package may contain other packages, which may in turn contain other Packages. But the "MOF2 Versioning Final Adopted Specification" doesn't mention about the versioning semantics related to containment of packages. Following are few concerns: If 'checkIn()' operation of a VersionedExtent object is called and if this VersionedExtent object contains other VersionedExtents, then should new versions be created even for the contained VersionedExtents ? If 'delete()' operation of a Version object is called and if this Version object contains other Versions, then should the deletion be performed even for the contained Versions ?

Package containment has no influence on versioning semantics, Extents cannot contain other Extents (which was a premise of the question) and that if an object in a versioned extent is deleted its contained objects are also deleted in the context of that workspace. In particular: 

·	Checking in a package in one versioned extent does not automatically check in a second versioned extent, whether or not the first versioned extent has packages that contain packages in the second versioned extent. 
·	Deleting a version for one versioned extent does not automatically delete a version of another versioned extent, whether or not the first versioned extent has packages that contain packages in the second versioned extent.  Resolution: 
Package containment has no influence on versioning semantics, Extents cannot contain other Extents (which was a premise of the question) and that if an object in a versioned extent is deleted its contained objects are also deleted in the context of that workspace. In particular: 

·	Checking in a package in one versioned extent does not automatically check in a second versioned extent, whether or not the first versioned extent has packages that contain packages in the second versioned extent. 
·	Deleting a version for one versioned extent does not automatically delete a version of another versioned extent, whether or not the first versioned extent has packages that contain packages in the second versioned extent.

From the MOF versioning specification its not clear , how to determine whether Extent is changed or not. In order to version an extent, first there is need to determine whether extent is changed or not. Is addition/modification/deletion of objects/slots/links considered as a change for an Extent? Can links go beyond extent? Can there be inter-versionedExtent links? If yes, then which extent 'owns' such links? and which extent is considered as changed? Is there any relationship with navigation of association, for determining which extent is changed?

In a versioning environment the extent must versioned and checked out before any changes can be made, otherwise it is read only.

Links can go beyond extents and are resolved in the context of the version that is in the current workspace: in that sense it does not matter which extent owns the link.

The storage of links (as instances of Associations) in extents is a general MOF issue and is not directly related to MOF versioning. Resolution: 
In a versioning environment the extent must versioned and checked out before any changes can be made, otherwise it is read only.

Links can go beyond extents and are resolved in the context of the version that is in the current workspace: in that sense it does not matter which extent owns the link.

The storage of links (as instances of Associations) in extents is a general MOF issue and is not directly related to MOF versioning.