SCM Meeting 2009-11-11

Agenda:

• Introduce new spec pages on wiki
• Discuss issues on the new page ScmSpecIssuesV1
• Discuss meetings and work to be done in the next few weeks

Minutes:

Present: NickCrossley, SamitMehta, FobinFuller, PeterHack

Nick went through the new wiki pages - the draft specs, and the issues page, describing the division of content between the top-level spec (mostly red tape and overall behavior issues) and the three lower level ones. In those lower level ones, much use will be made of the evolving shared specs for resource description, query, and service discovery, and that's one reason why they are still mostly empty.

We then reviewed the top-level spec. Following Scott's comment, Nick will replace paging section with the one from QM instead of CM, since the QM one is better. Nick: now done. Nick commented on three areas where the top level spec differed from the CM one from which it was mostly copied:

• SCM will require support for http, as well as recommending use of https. The wording of the other specs implied that they should support https, and did not have to support basic http; that seemed unnecessary, especially for deployment of an intranet integration.
• SCM providers may support the TRACE method; this seems an error of omission in the other specs where by implication the trace method must fail, since it is not in the table of allowed methods
• There are a few differences in the way we think selective properties should behave. First, the CM spec requires a GET request to fail if any of the requested properties do not exist. This does not seem to fit the SCM batch retrieval scenarios, where not all objects have the same attributes, but you want to retrieve the value for those that do have it. We prefer an approach where the request for certain properties does not fail, but just returns whatever does exist, including no selected properties. We could use the http response code 206 partial content - but that could be expensive to detect. There was also some inconclusive discussion about empty/null values and how they should be represented vs. missing attributes.
• Continuing with property retrieval, what if no specific properties are requested: do we return all, or a default set? CM 1.0 requires that all properties are returned. Again, this may not be appropriate for queries returning a very large number of objects. It seems there should be a way to return a default set (perhaps by not specifying a property set on the request) and a way to explicitly ask for all properties (perhaps using a parameter oslc_scm.properties=*).
• The issue of getting resource (file/document) content vs. resource description and properties has been raised elsewhere, and is of course an issue that needs to be resolved for SCM. Suggestions so far considered elsewhere have included treating these two things as separate resources with separate URLs, and allowing the client to request one or the other through the accept header while the server notes which one was returned through the content type. Nick does not like either of these approaches. Separate resources with separate URLs means that you cannot just get a resource URL for a file from one of our navigation queries and then GET its contents - the client would first have to convert the resource URL into a content URL somehow. It also means you cannot get the properties and content of a file in a single request. Overloading the meaning of the accept and content type headers seems wrong - and what if a file content had exactly the same MIME type as its OSLC resource properties? In other words, what if I took the response from a properties GET request, and decided I wanted to store that as the contents of a controlled file in SCM?
• The topic of selection delegates (in the first row of the SCM Resources and Operations table) is currently linked to a CM services page; we need to make this a shared spec, or copy and adapt it for SCM use. For SCM, we need to support a suggested Change v2 feature, where the delegation can first involve the user selecting a saved query, then the service provider running that query, then the user selecting from the query result using a GUI provided by the service provider. However, we would also want the OSLC SCM client to be able to provide a specific query; if the client provided a query, that query would be run, and the selection dialog presented with the results, while if no query was provided, the user would be prompted to select a saved query as previously described.

For the query syntax, the SCM group will adopt the common spec, adding SCM specific details as required.

In the resource definition document, Nick has initially provided a very skeleton outline of the resources and their common operations - basically, get content and get members. For resource represenatations, the SCM group will follow the shared OSLC approach, which right now is settling down on RDF, so GET requests will return RDF/XML. Do we also mandate a JSON representation? If so, is that just a standard JSON translation of the RDF, or is it a potentially more compact and readable custom representation?

Attendees agreed with there being no immediate need for separate symlink resource type

The group also reviewed the Issues page, with the following discussions:

• We agreed that we'll refine resource types and operations as we refine the services. There was some discussion about whether or nor we need to represent an object vs. an object version as separate resources. In many cases, the SCM operations we have defined would only need object versions, but if you start from a change set, and find an associated directory version, you might not be able to identify versions of files in that directory without additional context.
• Do we define specific common attributes for SCM? If not, how does a client use the services to do the common navigation implied by our scenario? Does service discovery do this mapping rather than the spec itself? So do we define a data model? Probably yes - but keep it very simple. Note that since we have no update services in v1, the service provider would need to be able to map the internal provider's data model to the OSLC model, but not vice versa. Defining a complete common data model across all SCM systems would probably be doomed to failure, so we should not even attempt that, but defining one that covers just the operations we provide should be possible - and it's difficult to see how we can provide the operations necessary for our scenario without doing so.
• Recursion count - we agreed that an arbitrary integer depth argument is not useful. What we want is zero, one, or infinity, plus possibly one intermediate level meaning 'down to the component, but exclude sub-components'. Whether or not we need that depends on the data model.

Nick mentioned he had updated the schedule, and would try to start some email threads to get the discussions moving outside the meetings. The new schedule has a one week lag from the CM 2.0 spec completion date, allowing the SCM spec to make any last-minute changes required to be compatible. There was some discussion on implementation schedules; for Synergy and CC at least, it would be difficult to do better than the suggested targets.