SCM Meeting 2010-02-03

Agenda:

• Continue listing common properties
• Start discussing relationships

Minutes:

Present: NickCrossley, DaveJohnson, ScottBosworth, SamitMehta, PeterHack

First, Scott brought up a request from BrendaEllis that OSLC provide baselines as a common feature across almost all providers - so requirements, models, test cases and results, and similar resources could be captured as part of a baseline as well as SCM resources such as versions of directories and files. Nick responded that this was certainly very desirable, and that there had been some discussion of common versioning capabilities in Telelogic tools before the acquisition by IBM, but that nothing concrete had come out of those discussions. Nick thought we should start by just getting baselines in SCM before trying to generalize it to other providers - doing otherwise would likely cause delays to the specs. There was some discussion of the capabilities of SCM baselines, including a discussion of the abstract SCM data model as shown in the diagram in the spec, using SCM baselines to control baselines of files, where those files contained data from other tools such as RM or QM tools, etc., and handling baselines of arbitrary resources that way - of course, that might not provide as fine a granularity as one might wish, and would certainly not provide as good a reporting capability as one would want. It was pointed out that Asset Management is strongly related to this whole issue of keeping general purpose baselines.

Nick continued by describing his recent changes to the resource spec - reordering the page to put change sets at the top, adding the link properties to all objects, and replacing owner strings by foaf elements.

We then continued working on the properties of SCM resources, starting with change sets.

Samit and Nick discussed the difference between a resource representing a specific version of a file, vs. one that represents an unspecified version, or the set of all versions. In the services proposed for SCM v1, there was a need for the resource representing a specific version of a file or directory (at this time, called a File or Directory, respectively, on the resource definition page), but no need for a resource that was a direct representation of the set of all versions. However, since future operations would almost certainly require this distinction, we agreed to rename the existing resources as FileVersion and DirectoryVersion, reserving the terms File and Directory for future resources representing an unspecified version or the set of all versions.

There was general agreement that seeing how many of the common properties were the same for all SCM resource types, and that in turn most of those were just copied form the CM spec, that there should be a core set of OSLC common properties that could be factored out of all the individual specs.

Scott asked if any progress had been made on reverse service discovery. Nick said that he had discussed this with Ian, and that Ian had suggested three possible solutions:

1. Use a GET on the resource URL with an Accept header to indicate that you don't want the resource itself but its service description (Nick did not like this approach - it seems abuse of the Accept header)
2. Have every OSLC resource contain a common property that is the URL for the service description of the owning provider - this seems preferable

Scott also asked if any progress had been made on distinguishing resource content from resource metadata; Nick said no, this was still an open issue for SCM. Tentatively, the two are provided by different operations - that is, there would be a difference in the query part of the URL. Scott mentioned that progress had been made on this issue in the Asset Management group, and Nick agreed to review that spec.

Nick mentioned that most SCM systems provided security features, where access to all or part of a resource might be denied, and asked if other OSLC workgroups has specifically addressed this. The answer was that, no, current OSLC specs did not explicitly address this, and so the likely behavior would be that operations might fail, or might succeed but return only the accessible properties of some resources.