[oslc-scm] Making OSLC SCM less file-centric

[Frank Schophuizen]

*Remark 1:
*If we abstract files and directories into VersionedObjects, we must take
into account that VersionedObjects could be any versioned entity, not only
files and directories. We might even assert that a non-versioned object is a
VersionedObject with only 1 version (ever). So we must be careful not to
imply all-and-every object type under VersionedObjects.

*
Remark 2:
*The definition of Configuration will / may change into:

Configuration - a thing that has a specific version of a one or more top
> level *VersionedObject*, and under those specific versions of any number
> of *VersionedObjects*.
>

This sounds odd... If we abstract files and directories into
VersionedObjects, we still must distinguish between
CompositeVersionedObjects and AtomicVersionedObjects, where
CompositeVersionedObjects are VersionedObjects that can contain (other?)
VersionedObjects, and AtomicVersionedObjects cannot. This way, the
configuration will become:

Configuration - a thing that has a specific version of a one or more top
> level *CompositeVersionedObject*, and under those specific versions of any
> number of *VersionedObjects*.
>

But why should a configuration be a (one or more) "directory" (or
CompositeVersionedObject)? A configuration can also be one or more
(individual) "files" (VersionedObjects) that "belong" together to a specific
reason. For example, a configuration could be "all source files" or "build
results of build 123" even when they are spread across multiple directories.


*Remark 3:*
I think that a definition with "a thing" is not accurate enough. I propose
to call it a "collection" or a "set".
And "one or more top level" is also to vague. What is "top level" and why do
we need to distinguish between "zero" and "one or more"?
Proposal: Configuration - a collection of a specific version of (a number
of) CompositeVersionObjects.


*Remark 3:
*I think we need the term "configuration" and "configuration item" because
it is a commonly used term in SCM practice, even though the terms are often
unclear or even undefined. A configuration may be considered identical to a
CompositeVersionedObject (which results in a possibility of nested
configurations) and a configuration item may be considered identical to a
VersionedObject.


*Remark 4:
*
>
> Baseline - a frozen configuration. [...] a baseline can be an incremental
> baseline, with a link to some previous incremental or full baseline.
>

A baseline being incremental or full, linked to other baselines or not is an
implementation choice of the provider. In all cases, it remains a frozen
configuration, i.e. a reproducible, immutable configuration.


*Remark 5:
*Component - an abstract concept representing some user-defined
configuration or set of configurations

I think a component should not be an "abstract" concept. It should be "an
identifiable configuration". A configuration could be an abstract concept
IMHO, but a component should not be.
Moreover, I think that baseline and component are both identifiable
configurations, uniquely named within the relevant namespace.
In addition, I think that a component is a CompositeVersionedObject. Since a
CompositeVersionedObject is a VersionedObject that can contain
VersionedObjects, a component is a structure with a single entry point.

We might even argue that the definition of "baseline" could be narrowed down
from "frozen configuration" to a "frozen configuration of components", in
order to distinguish from configurations of any type of VersionedObjects. On
the other hand, that would disable the possibility of a
baseline-of-baselines.


*Remark 6:
*In this sentence:

> *required* properties must be provided for any resource when requested;
> this does not imply that these properties are provided by default.
>

I think this is contradictive. To me "must be provided" means the same as
"are provided by default" (maybe it's my lack knowledge of English idiom).


*Remark 7:*
those that do not exist will not be present in the returned representation
even if requested

This should be extended with "those that do exist will be present in the
returned representation if requested".


So much for now... I will read the rest of the definitions later.

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/20100222/57cae001/attachment-0003.html>