Re: Review of 'change set' terms & shapes

["Nick Crossley" <ncrossley@us.ibm.com>]

Some initial responses to Martin's comments:

- How to treat a selection or contribution that has been removed as part of the change set
At the moment, I was not attempting to address changes to GCs. The ChangeSet resource is intended to reflect what a local provider might use to represent a set of changes IN a local config - such as 'I added this file, changed the content of that one, and removed this one'. Such changes could be represented as a delta configuration with new or modified selections for the additions and changes, and as a different (currently unspecified) relationship for the removals, or could be represented as a complete configuration showing the result of the changes.
If we want to have a representation of changes TO a configuration, as opposed to changes IN a configuration, then I would probably suggest something like the patch mechanism has already defined for TRS events (the spec for which is currently in my hands, in a backlog of stuff to move to the OASIS Core TC after we are done with the Core 3.0 itself).

- At a more fundamental level, I suppose the question is why change sets need to be exposed as consumable external resources. Of course internally they satisfy an important requirement which is to represent the difference between two change sets in a handy format. But will an external application need this? What is the use case?
- Using the term "overrides" certain suggests a particular meaning for the related configuration.
A change set (whether it is represented as a complete configuration showing the end result of the change, or a delta to some other configuration) most likely applies to some configuration; a change set in and of itself might be interating for reporting use cases, but in normal development, you want to apply that change set to a target configuration. Even if the change set itself represents the end result of that application, a user would want to know which configuration was the target, because you would not want your global configuration context to include both the 'before the change' state AND the 'after the change' state - that would likely result in version skew. So, the change set has this important 'overrides' relationship that denotes the target config whose selections must be either replaced with or updated by the change set selections. The semantics of that relationship were not included in my draft because I wasn't sure if we were ready to decide if the change set was a delta or a replacement - or if we should allow both, with two different link types from the change set to the target configuration.

- why is there no "Configuration shape"
There used to be - I removed it when we added the subtypes 'Baseline' and 'Stream', because I assumed all configurations were going to be one of those two new types - so either the Baseline shape or the Stream shape would apply, and they have different properties from each other. I am happy to put a generic Configuration shape back in, though it would not adequately describe the constraints on any specific configuration; we'd have to decide whether a Configuration shape should represent the union or the intersection of Baseline and Stream shapes.

Nick.