SCM Meeting 2010-02-17

Agenda:

• Review common properties
• Discuss operations and their results

Minutes

Present: NickCrossley, RobinFuller, SteveSpeicher, PeterHack, DaveJohnson, SamitMehta

Nick mentioned that he had posted minutes of previous meetings, and updated the issues list.

We started by reviewing the issues list; Nick has separated out the issues specific to SCM vs. those that might be addressed in the core spec. On the issues specific to SCM, Nick noted that has noted where progress has been made, and has moved several items to the 'Resolved Issues' list lower down the page.

We discussed the question of resource representations, including the question of whether or not we mandate and/or define a JSON representation. Dave Johnson mentioned that the core spec might define rules for generating representations from abstract resource definitions, in which case a JSON representation might effectively come for free.

We skipped any significant discussion of the non-SCM-specific items, since Nick wanted to leave time to go over the new material on the resource definition pages.

Nick started the discussion on the resource definitions by noting the changes made as a result of the agreement last week to change File to FileVersion and Directory to DirectoryVersion. This change allows us to add non-version-specific resources in the future.

The FileVersion resource now has properties to access the file content, copied from the Asset Management spec; one question that arises is whether or not we need two different ways to get the contents (as an inline property, and/or as a separate resource URL). This led to a discussion of the MIME type property; Nick pointed out that the MIME type property was not as useful as one might think, in that it does not adequately distinguish between the encoding of the content as returned in an HTTP response, and the format/semantics of the underlying content itself. Dave mentioned that the Asset Management spec relied on the Atom Publishing Protocol for some of these definitions. One possible advantage of the reference property is that the separate content URL could be handed off to clients (human or code) that were not OSLC-aware, and did not understand RDF/XML, etc., but just wanted a link to the file content itself. Nick agreed to chase up these issues with Dave and the other groups.

The new content properties on FileVersion are defined as mandatory. Note this does not mean that every GET request on a FileVersion (and GET requests on baselines and components with the recursive option set) must return one or more potentially very large file contents; indeed, the file content properties would not be in the default set, so would not be returned unless specifically requested (in oslc:properties). The intended meaning of mandatory in this part of the spec is that those properties must be returned for any FileVersion resource, if explicitly requested.

Nick then went on to explain the GET requests on the various resource types that had been added to the spec. The GET request on change sets was not recursive, so returned only the properties of the change set itself, and (if requested) the inlined properties of the immediately associated changed object versions. The GET request on baselines and components allows an optional parameter to specify the degree of recursion; this is to allow efficient queries for the contents of a baseline while retaining any hierarchical structure. As agreed in previous meetings, four degrees of recursion may be specified - 0, 1, infinite, and within one component. The GET request on a directory may recurse down through subdirectories and/or subcomponents if and only if a baseline or component is provided as a context; this is necessary because a given directory version can contain different versions of members, and hence different members below those, in different contexts.

The GET requests on file versions and directory versions with the oslc_scm:delta parameter provide the difference between two object versions (most often, two versions of the same object, but the spec allows for returning the difference between any two arbitrary object versions). Note that we have not yet defined the diff output format or formats - how many do we want to define?

Nick explained that he had also added dc:title as a property to both FileVersion and DirectoryVersion because the dc:name field was not unique, but the dc:identifier property might not be intended to be human readable.