[oslc-scm] SCM 1.0 spec updated to follow core spec draft - ready for convergence?

[Nick Crossley]

Frank, thanks for the feedback.  My responses below should address both 
your comments, and those from Harsha.

> Remark 5: Configuration
> The text "top level objects" appears first here. It is not clear how
> top level objects differ from other objects. May be it intended to 
> define that a configuration contains a single entrypoint which acts 
> as a "handle" to the configuration.

Sorry, I thought I had addressed this previously-mentioned concern of 
yours in the expanded text.  I have now revised the text again to try to 
make it even more clear.  A configuration contains a hierarchy of objects 
with zero or more direct or immediate members at the top level of the 
hierarchy; these are the top level objects.  Each of those objects may in 
turn have zero or more members, thus forming the hierarchy.  The member 
property gets you exactly one level and no more, unless you specifically 
request more using either the nested property syntax 
member{propertyName,...} or the oslc_scm.recurse parameter.
 
> Remark 6: Directory Version Properties
> The description of oslc_scm:memberName suggests only files and 
> directories. But in the definition of "Directory and file versions" 
> it is stated that a directory may contain (sub)configurations. The 
> property should be able to return those (sub)configuration names too.

I have fixed this.

> Remark 7: Directory Version Properties
> The memberName property may be too limited to identify the members 
> of a directory version for comparison. For example if version 1 
> contains a member foo.c, versions 2 until 5 contain no member foo.c,
> and version 6 contains a member foo.c, it is uncertain whether both 
> foo.c members are versions of the same object or versions of 
> different objects (which happen to have the same name).
> In an SCM system, members of the same name may occur multiple times 
> as long as they are contained in different directories (= different 
> directory paths).
> I propose to add a properties uniqueName to return a unique 
> identifier in the repository namespace, to distinquish between equal
> memberName values. The layout of uniqueName is provider-specific, 
> which means that uniqueNames cannot be compared/reused across 
> providers but memberName can.

The property name was misleading - it was not intended that this be a 
simple (and thus ambiguous) file name; instead, this property was intended 
to be what you have termed the uniqueName.  I have renamed the property 
memberIdentifer, and expanded the explanation.  Note that in some SCM 
systems, you might not know the actual file name (or subdirectory name, 
symlink name, etc.) until you know the version, since the file might have 
been renamed at some point in its history.

> In addition, we have to add to the definition of memberName that a 
> directory version does not contain multiple members with the same 
memberName.
> 
> And we must be clear whether the OSLCM_SCM spec permits case-
> insensitive names ("MakeFile" = "makefile") or case-sensitive names 
> in memberName.

As for uniqueness constraints, case handling, etc., they differ from 
system to system, client to client, and file system to file system.  Since 
SCM 1.0 is only reading existing data and has no defined services to 
create or modify objects, I do not believe we need to define how those 
uniqueness constraints work.  Nonetheless, I have added some text about 
this issue in the data model section at the top of the SCM Resources.

> Remark 8: Symlinks
> Add that service providers for systems that do not support symbolic 
> links MAY use the Symlink resource. For example, ClearCase supports 
> symlinks on Windows systems, although in the work area (on the 
> Windows file system) the symlinks are translated into copies.

Agreed; I have added a note to this effect.

> Remark 9: Symlinks
> The current definition assumes that symlinks are "file system path".
> But I propose that a symlink can also be a URI (string) to an object.

Earlier drafts of the spec allowed this (a link to another resource).  In 
a recent meeting, we decided to simplify the spec by eliminating this, 
because none of the initial implementations of SCM services support links 
to other controlled resources, and because the core spec has a way for a 
service provider to define and use resource types above and beyond those 
defined in a domain spec.  Thus a future service provider for an SCM 
system that did provide links to other resources can define its own 
resource type, and return link resources of that type.  I have now 
mentioned this in the spec.

> Remark 10: Directory version
> Remark 9 brings me back to the definition of a directory. A 
> directory version should be capable of containing a symlink.

I have fixed this in the description of the directory version resource.

> Remark 11: Symlinks
> Add that a symlink is a specific type of object version. If not, 
> then changing a symlink will update all prior baselines that contain
> the symlink.

All SCM 1.0 resource types are subtypes of object version, including 
symbolic links.  This is specified in the description of the object 
version resource type.

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-scm_open-services.net/attachments/20100418/ba2e98fc/attachment-0003.html>