I’m going through the config spec and had some notes specifically related to issue 29 but also some other notes.
General notes:
1.
I really could use a diagram to illustrate how these resources are conceptually related to each other. It need not be a complete UML diagram showing all the metadata – that would be too busy. But for sure something showing the relationship
between component, configuration, baseline, stream, etc.
2.
Where is the shape for config#Configuration?
3.
The oslc_config:selections property references oslc_config:ChangeSetSelections which is not specified
PUT: …. Might or might not … should be MAY …
This issue is resolved by introducing the concept of change sets and the oslc_config:overrides property, however the verbiage could use some tightening up – along with points 2 and 3 above.
The configuration defined by a change set thus identifies both the 'before' state (the base configuration that is
overridden by this change set), …
Do you really mean prov:wasDerivedFrom here? Isn’t this oslc_config:overrides?
When a change set is based on a stream (the prov:wasDerivedFrom property on an instance of an oslc_config:ChangeSet…
Providers can avoid this lack of precision by ensuring either that all changes made to a stream are
either captured….
… or that the selections resource of the stream stream’s oslc_config:selections property …
The bottom half of the paragraph is OK but it is really tough to parse. I think my recommendations may be enough.
Is this normative?
Systems that allow a single change set to be applied to multiple base configurations
must represent that internal change set by …
|
|
|
Dr. Martin Sarabura |
