[OASIS Issue Tracker] (OSLCCCM-17) Potential confusion about oslc_config:previousBaseline

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61440#comment-61440 ] 

Nick Crossley commented on OSLCCCM-17:
--------------------------------------

The current intent is basically as described by David, which is almost the same as that described by Geoff, with some slight differences for a weaker form of inheritance for a new stream.

When a baseline is created for a stream, then the oslc_config:previousBaseline property of that stream must be updated to point to the new baseline; we all agree on that.

Where a new stream is intended to be a different branch of an existing stream, and is derived from some baseline of that stream, then oslc_config:previousBaseline of the new stream must point to the baseline from which it was derived.  I did not intend prov:wasDerivedFrom to be needed in this case, but having it in addition to oslc_config:wasDerivedFrom is harmless.

A tool *may* offer a gesture that creates a brand new stream, but whose contents may be copied from some existing baseline or stream; in such a case, the tool should use prov:wasDerivedFrom to indicate the resource from which the contents were copied, and oslc_config:previousBaseline should either be absent, or point to the initial empty baseline of the component.

The current spec does not define operations to merge baselines, nor does it define operations to 'update' a stream from a baseline. The spec does contain some language to address what effect a merge might have on oslc_config:previousBaseline, but is inconsistent in not having any equivalent language for a possible update operation. Historically, the reason why merge was mentioned but 'update' was not is that merge is the one reason why the property might be multi-valued. It is important to describe the property as multi-valued so that clients are able to handle that from day 1, otherwise it would be very difficult to change the cardinality in future versions of the spec that do define merge or update operations.  Nonetheless, I think it would be the right thing to do to be consistent, so I think the spec should change to mention the effect that both operations would have, if servers were to implement such operations.

For merge, I think we all agree that each of the baselines merged in must be added as an extra value of the oslc_config:previousBaseline property.

For 'update', I think the best approach is to say that the existing value of oslc_config:previousBaseline on the stream is replaced to point to the baseline from which the update is performed, and that no other changes (to any existing baselines) are made. This results in an effective branch to the history of the stream: suppose I have a line of baselines and a stream at the end:

b1 <--- b2 <--- b3 <--- stream

then I perform an update from b2, do some work, create a new baseline b4, I get:

b1 <--- b2 <--- b3
               \--- b4 <--- stream

> Potential confusion about oslc_config:previousBaseline
> ------------------------------------------------------
>
>                 Key: OSLCCCM-17
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-17
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>
> The description of oslc_config:previousBaseline for a stream in https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt/config-resources.html says this:
> "A reference to the immediately preceeding baseline of this stream. Multiple instances of this property imply the stream was merged from one or more baselines, and no baseline of the merged result has yet been taken. If the property is absent, no baseline of this stream has been taken."
> I believe the intent is that this predicate references the most recent baseline created from a stream, and not the configuration that the stream was copied from (which prov:wasDerivedFrom would describe). However, the description hints at both meanings, and I know of at least one implementation that has interpreted it as the latter, and a different implementation as the former.
> If I have understood the intent correctly, I suggest the following changed wording:
> "A reference to the most recent baseline created from this stream.  If the property is absent, no baseline of this stream has been taken. Multiple instances of this property imply the stream was merged from one or more baselines, and no baseline of the merged stream has yet been created."



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)