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

[Frank Schophuizen]

*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.

*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.

*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.

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.

*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.

*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.

*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.

*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.

== that's it for today ==

Feel free to comment on my remarks.

Frank.
-- 
TOPIC Embedded Systems
P.O. box 440, NL-5680 AK Best
Netherlands
Phone (+31) 499 336979
Fax   (+31) 499 336970
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-scm_open-services.net/attachments/20100417/f5f3135c/attachment-0003.html>