SCM Meeting 2010-02-24

Agenda:

• Making the spec less file-centric
• Feedback on resource definitions and GET requests
• Schedule
• Prototype implementations

Minutes

Present: NickCrossley, JeanMichelLemieux, SamitMehta, RobinFuller, DaveJohnson

The group started discussing genericising the SCM spec to be less file-centric. Some concerns were raised about the costs of the changes, on performance, and on applicability to potential clients. The group also discussed the motivation for the change (for example, to be able to report on baselines that might contain objects other than file-based types, potentially including direct representations of requirements, architectural and model diagrams, etc, as opposed to just files containing such data). After some discussion, the group agreed with Nick going ahead with changing the spec to add more abstract object types for further review.

We discussed the comments and questions from FrankSchophuizen. Nick mentioned that several of the comments regarded changes to the definitions of various resources, and that Nick would incorporate several of these comments as part of the re-wording of the definitions to be more generic. Nick also agreed with some of the other suggestions made by Frank, including making it more clear that change sets might not be atomic in all cases - a change set might be partially included in a configuration for a variety of reasons.

On the suggestion of defining two types of object, CompositeVersionedObjects and AtomicVersionedObjects, where CompositeVersionedObjects are VersionedObjects that can contain other VersionedObjects, and AtomicVersionedObjects cannot, there was some discussion, but Nick deferred a decision until Paul and Peter were available.

Similarly, we deferred the question of whether or not an incremental baseline was a useful concept to expose - and noted that SCM systems did not in general guarantee to keep track of previous baselines of baselines, back to the beginning of time. Once a baseline has been created, it is possible that its original baseline is lost, deleted, or otherwise made unavailable. For this reason, the OSLC SCM API should not guarantee the availability of such a 'baseline's baseline' property.

Samit asked about how OSLC property names mapped to actual provider properties. Nick explained that the providers were expected to map the property names defined by OSLC, but that providers should also be able to expose any or all underlying properties using the provider's name. We need to define a way for clients to request these unmapped names. Dave explained how the core spec would define a number of core properties, and how the core spec would require each higher-level OSLC spec to provide 'resource shapes' that would define the topic-specific resource types and their known properties. This led on to a discussion about how property names might need to be associated with translatable labels to be shown to end users.

There was some (inconclusive) discussion of the proposed new schedule, and the state of web service implementations in RTC.

Finally, the group agreed to use the unified diff format as the default format returned by the source comparison operation, but providers would be at liberty to define additional formats with extra query parameters.