Should the workgroup address partial configurations - configurations whose specification is incomplete, resulting in more than one candidate version of one or more resources?
Issue 4
We need to prototype the designs for global configurations, and for passing configuration context. Having four different ways to pass the configuration context is too complex, and we should almost certainly reduce this to just two (one using a header and one using a book-markable URI).
Issue 5
Version skew needs further discussion. Do we need to define a standard way to represent version skew for those systems that support it, or can we just say that the standard does not support version skew, so the only way to represent version skew using the standard is to use multiple configurations, with a defined way to link to resources in a different configuration.
Issue 6
How are deleted (or removed) CIs represented in a change set?
Issue 7
We need to track evolution of the Linked Data Platform, ensuring correctness of our use of features such as non-member properties for containers.
Issue 8
Global configurations - how are these represented? Current proposal is that they are represented as configurations that contain other configurations as members. Note that this does not imply that non-global configurations necessarily support configurations of configurations.
Issue 9
Dependencies between configurations: do we need to represent them?
Issue 10
Dependencies between change sets do we need to represent them? Why is the oslc_config:requiredChangeSet property of a ChangeSet defined? What use case or scenario requires it?
Issue 11
Tagging of configurations for search and identification purposes: should we define a standard way to represent properties of configurations that may be used (independently or in combination) to identify and distinguish configurations and the purposes for which they are used? For example, do we want to standardize the notion of dimensions in a variability space, and use dimension values to tag configurations?
Closed Issues
Issue 1
How should the configuration management specification address structure, containment, hierarchy, etc., of configuration items? What does it mean to say a resource is in a configuration?
Resolution: the configuration management vocabulary shall not define terms for any such structure. The specification will allow a configuration resource to have multiple types, including a linked data platform container, a PLM item or view, or any other resource type that implies member resources. However, the workgroup strongly recommends that all future OSLC specifications use Linked Data Platform containers, aggregations, or other well-defined structures where possible, rather than inventing domain-specific containers and collections, and we suggest that future OSLC Core specifications make this same recommendation.
Resolution: the OSLC spec defines a simpler change set resource that contains zero or more links to CIs - with version-specific links or links with a configuration context, so the change set identifies the exact version of each resource. For added and modified resources, these links point to the version of the resource that is the result of the specified change; the version of the resource before the specified change may then be found using the provenance link prov:wasRevisionOf.
