Baseline: a term for a configuration that identifies an immutable set of resources with immutable states. Baselines often have other identifying properties, such as particular workflow or approval states. A baseline resource might be mutable. In some domains and tools, it may take time to construct the baseline during which the set of member resources might be changeable, but the member resources are immutable. At some lifecycle stage, the baseline might undergo validation and approval at which point the collection becomes immutable.
Branch: a branch identifies a set of version resources (revisions) that form a parallel variant of a concept resource - for example, a set of versions of a product for a particular geography or market. The term is also used to identify the point in the version history at which that new branch was created, and the parent version from which the new branch was derived. Finally, as a verb, branch is also used to describe the action of creating the initial parallel version.
Change set: a resource that identifies a set of related changes to one or more other resources. Not all systems support explicit creation and management of change sets. The use cases and scenarios defined by this work group require change set resources as an intermediate resource between OSLC change requests and configuration items when using the defined link predicate oslc_cm:tracksChangeSet, and as part of the representation of baseline comparisons, but a provider may construct these change set resources implicitly, dynamically, or in other manners as required. Note that OSLC change requests may also have other links pointing directly to configuration items.
Concept resource: All the major “Artifacts” or “Entities” in OSLC domains and equivalent linked data providers are concept resources. Examples are defects, tasks, products, projects, users, tests cases, designs, requirements, plans, and so on. Like all resources, concept resources have URLs. In most cases, URLs of concept resources are used throughout a system. “Entities” are addressed in HTTP messages via their concept resource URLs. Again in most cases, links are established by using the URL of a concept resource.
Configuration: a resource that identifies a set of revisions, versions, and/or states of some other resources, possibly including other configurations. In some systems, a configuration identifies an exact set of resources selected by the entity that created the configuration, as well as their versions; in other systems, a configuration may identify the state of a fixed set of resources, not limited to a client-determined set. The implication is that a client cannot rely on being able to create a configuration that ‘contains’ only a client-specified set of resources.
Configuration item: this is a common term in configuration management, referenced in ISO9001-1003, MIL-STD-498 and elsewhere. It encompasses any type of resource whose state may be recorded by a configuration - that is, a type of resource that may be ‘in’ a configuration. A configuration may be (but is not required to be) a configuration item.
Configuration management: the practices of managing configurations, their contents, their lifecycles - in particular, identifying and controlling changes to configurations.
Configuration space: Typically, resources belong to some service provider, and are stored in some container. These service provider and container boundaries often imply constraints on which set of resources can comprise any single configuration. A configuration space identifies the set of versioned concept resources that may be members of the same configurations. A versioned concept resource is associated with just one configuration space.
Configuration specification: A set of rules that specify versions of resources to be selected in a configuration using this specification.
Context: A context is the description or specification of a configuration; that configuration might or might not yet exist (since we need a way to specify a configuration to be created). One way to identify a context is to use the URI of a configuration resource. Some providers may allow other mechanisms for specifying context. The term effectivity is used in some disciplines to indicate the extent of some configuration context, such as a period of time, or a range of serial numbers, etc.
Dimension: Different versions and variants of a single concept resource may be viewed as existing in an n-dimensional variability space, where time is one dimension and other feature or capability lines of variation define the other dimensions. A provider is not required to implement variability dimensions in this manner, but it may be useful to label configurations in terms of the points in this variability space. A branch in this view corresponds to a fixed set of dimension values other than time.
Effectivity: Defines the extent of applicability of some configuration specification, and thus is part of the definition of a context.
Global configuration: A configuration that aggregates configurations, possibly from multiple different providers. For example, a global configuration would be used to aggregate configurations from Rational Team Concert SCM, Git SCM, Rational Design Manager VVC, and other such providers. Global configurations can record baselines from tools from multiple vendors across the entire lifecycle.
Resource: In this context, we refer to an information resource - data that resides on a computer, not an actual physical entity.
Revision: In the software configuration world, this term is often used for a version of an resource that is designed to replace an earlier version, such as a new version of a source file or a revised requirement. In the hardware world, the term revision often has a more precise meaning with implications about the scale of a change. To avoid confusion, the OSLC Configuration Management specification should avoid the term.
Stream: a term for a configuration that identifies a mutable set of resources, with mutable states and/or different versions. Streams typically serve as areas for ongoing development; baselines are typically formed by taking a snapshot of (recording the current state of) a stream and the configuration items in that stream.
Variant: A variant of a resource (configuration item) is a version that may exist at the same time as one or more other variants, and is identified by a specific set of characteristics, features, or capabilities that distinguish it from other variants of the same resource. For example, the Coupe Si, Sedan Si, and Hybrid may be variants of a vehicle product. From the point of view of configuration management, a variant may be treated in the same manner as time-based versions, just differing along other non-time-based dimensions.
Variation point: A choice point within a resource where a selection defines one of the characteristics that distinguish one product from another within a product line. In software configuration management, a variation point is often indicated using techniques such as the #ifdef construct in C; in the hardware or electronics world, it might be indicated in the build instructions, substituting one of several possible components at a given location, or by the omission of an optional component,
Version resource: A version resource defines a particular version of the state of a concept resource. A version resource is a version of one and only one concept resource - though note that through redirection or some other form of mapping, a GET on a concept resource URI might resolve to a different concept resource, or a version of a different concept resource. There are use cases for links that always identify a specific version resource.
Version skew: the situation where two different versions of the same concept resource are used in different places in some context or related set of contexts. For some providers, a single configuration by itself cannot support version skew, while some providers might be able to represent version skew within a single configuration by adding additional information about the location of an instance of a resource within the configuration. Since many providers cannot represent version skew in a single configuration, but version skew does exist in the real world, the detailed scenarios developed by this workgroup must explain how that real world version skew could be represented using multiple configurations (including the possibility of allowing configurations to be members of other configurations, or allowing configurations to reference or depend on other configurations). The scenarios should also describe how single configurations may be used for providers that can support version skew in a single configuration. Note: Since describing both options in a single scenario may result in text that is too vague, it may be better to have multiple sets of scenarios - a set of scenarios for providers that do not allow version skew in a single configuration, and a set of scenarios for those that do.
Workspace: A projection of the version resources in a stream to some container (such as a filesystem directory) that allows work to be performed on those resources.
Other possible terms: merge, option, view, recipe
