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 remember 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 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.
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.
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.
Resource: in this context, we refer to an information resource - data that resides on a computer, not an actual physical entity.
Revision: a revision is a synonym for a version resource
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 configuration item is a version that exists at the same time as one or more other variants. Variants are commonly used in Systems Engineering, to present different variations in product features or capabilities. 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.
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.
Other possible terms: merge, option, view, effectivity, recipe
