OSLC Configuration Management Version 1.0. Part 3: Configuration Specification (original) (raw)
Notices
Copyright © OASIS Open 2013-2021. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This specification is published under the Attribution 4.0 International (CC BY 4.0). Portions of this specification are also provided under the Apache License 2.0.
All contributions made to this project have been made under theOASIS Contributor License Agreement (CLA).
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Open Projects IPR Statements page.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Open Project or OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Project Specification or OASIS Standard, to notify the OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Open Project that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Open Project Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please seehttps://www.oasis-open.org/policies-guidelines/trademark for above guidance.
Table of Contents
- 1. Introduction
- 2. Service Discovery
- 3. Component and Configuration Constraints
- 4. Configuration context
- 5. Supported Operations on Components
- 6. Supported Operations on Configurations
- 7. Supported Operations on Selections
- 8. Supported Operations on Versioned Resources in a Configuration Context
- 9. Creation of Baselines and Streams
- 10. Contributions and Overrides
- 11. Version Resolution
- 12. Change Sets
- 13. Delegated UIs
- 14. Compact Rendering
- 15. Tracked Resource Sets
- 16. Query Support
- 17. Matching Contributions
- 18. Long Operations
- 19. Conformance
1. Introduction
This section is non-normative.
1.1 Typographical Conventions and Use of RFC Terms
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1.2 References
1.2.1 Normative references
[ABNF]
D. Crocker; P. Overell. Augmented BNF for Syntax Specifications: ABNF. IETF. Internet Standard. URL: https://tools.ietf.org/html/rfc5234
[CORS]
WHATWG contributors. Fetch standard. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/commit-snapshots/d070ea245c6eb66cf4196324f063dc6ab608d9e6/#http-cors-protocol
[OSLCCore3]
Jim Amsden. OSLC Core Version 3.0. Part 1: Overview. OASIS. URL: https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html
[OSLCQuery]
Jim Amsden; S. Padgett; S. Speicher; David Honey. OSLC Query Version 3.0. OASIS. URL: https://docs.oasis-open-projects.org/oslc-op/query/v3.0/oslc-query.html
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF, March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF, May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[URI]
T. Berners-Lee; P. Overell. Uniform Resource Identifier (URI): Generic Syntax. IETF. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986/#section-1.3
2. Service Discovery
A configuration server SHOULD implement [OSLCCore3] ServiceProvider and Service resources, where anoslc:domain
property has the value http://open-services.net/ns/config#
.[CONFIG-RES-1]
A global configuration service resource, if provided, SHOULD include the property oslc:usage
with the value http://open-services.net/ns/config#globalConfigurationService
.[CONFIG-RES-2]
A service with this usage property MUST provide all global configuration capabilities described as mandatory in this specification.[CONFIG-RES-3]
3. Component and Configuration Constraints
This section describes constraints on the resources for components, configurations, and related artifacts.
Configuration Management servers MUST observe these constraints, but MAY provide additional classes, properties, and individuals.[CONFIG-RES-4]
In particular, Configuration Management servers MAY define additional types of configuration, but all configurations MUST also be of one of the types defined here.[CONFIG-RES-5]
3.1 Resource shape for Component
- Describes:
http://open-services.net/ns/config#Component
- Summary: The shape of a component.
- Description: A set of versioned resources; a configuration selects zero, one, or (very rarely) more than one version of these resources.A component itself MAY be a versioned resource [CONFIG-RES-6], indicated by the RDF type
oslc_config:VersionResource
on its versions, but need not be versioned; the semantics of versioned components are not defined by this specification. Typically, components themselves are not nested - that is, typically none of the members of anoslc_config:Component
container are themselves of typeoslc_config:Component
; any required structure and hierarchy is realized through configurations, or through the structures within the configuration items themselves (e.g., versioned folders or directories). Component Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:contributor | Zero-or-many | unspecified | AnyResource | Either | foaf:Agent, foaf:Person | Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:created | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-7]. |
dcterms:creator | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:description | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Descriptive text about the resource, represented as rich text in XHTML content. |
dcterms:identifier | Zero-or-one | true | string | N/A | Unspecified | A unique identifier for this resource. |
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-8]. |
dcterms:subject | Zero-or-many | false | string | N/A | Unspecified | Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. |
dcterms:title | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Title of the resource, represented as rich text in XHTML content. |
oslc_config:configurations | Exactly-one | true | Resource | Reference | ldp:Container | The Linked Data Platform Containerthat contains all the configurations (both streams and baselines) of this component.The oslc_config:configurations property on a component is read-only; servers MAY also treat the referenced container as read-only [CONFIG-RES-9]. If it is not read-only, the container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-10]. If a container resource shape is specified, the shape SHOULD have a property describing the membership of the container with aoslc:valueShape referencing a resource shape that describes the shapes of streams and baselines that may be created [CONFIG-RES-11]. |
oslc:archived | Zero-or-one | unspecified | boolean | N/A | Unspecified | Indicates whether the subject has been marked as archived, no longer an active resource. |
oslc:instanceShape | Zero-or-one | true | Resource | Either | oslc:ResourceShape | The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. Instance shapes may be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource, and other factors, so instance shapes SHOULD NOT be cached [CONFIG-RES-12]. |
oslc:modifiedBy | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | The entity that most recently modified the subject resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
oslc:serviceProvider | Zero-or-many | true | Resource | Reference | oslc:ServiceProvider | A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property. |
oslc:shortId | Zero-or-one | unspecified | string | N/A | Unspecified | A short and human-readable identifier for the resource, such as a number. |
oslc:shortTitle | Zero-or-one | unspecified | XMLLiteral | N/A | Unspecified | A short title for the resource, represented as rich text in XHTML content. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI. A Component MUST have a resource type of oslc_config:Component [CONFIG-RES-13].A component MAY be a Linked Data Platform Container, containing the concept resources associated with this component [CONFIG-RES-14].The members of such an oslc_config:Component container MUST NOT be of type oslc_config:Configuration [CONFIG-RES-15]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a member of type oslc_config:Component; neither client nor server is obligated to perform any recursion through nested Components.Servers MAY treat the rdf:type property for a component as read-only. [CONFIG-RES-16] |
3.2 Resource shape for Baseline
- Describes:
http://open-services.net/ns/config#Baseline
- Summary: The shape of a baseline. Properties of a baseline defined in this specification MUST be read-only unless stated otherwise [CONFIG-RES-17]. Baseline Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:contributor | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:created | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-18]. |
dcterms:creator | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:description | Zero-or-one | unspecified | XMLLiteral | N/A | Unspecified | Descriptive text about the resource, represented as rich text in XHTML content.The description of a baseline MAY be modifiable [CONFIG-RES-19]. |
dcterms:identifier | Zero-or-one | true | string | N/A | Unspecified | A unique identifier for this resource. |
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-20]. |
dcterms:subject | Zero-or-many | false | string | N/A | Unspecified | Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource.Tags on baselines MUST be modifiable [CONFIG-RES-21]. |
dcterms:title | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Title of the resource, represented as rich text in XHTML content.The title of a baseline SHOULD be modifiable [CONFIG-RES-22]. |
oslc_config:acceptedBy | Zero-or-many | true | Resource | Reference | rdfs:Class | A type of configuration that accepts this configuration as a contribution.A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-23] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare. |
oslc_config:baselineOfStream | Exactly-one | true | Resource | Reference | oslc_config:Configuration | Indicates the stream of which this is a baseline. Note that the referenced resource might no longer exist (streams are mutable so can be deleted), but this property remains valuable to relate all baselines of the same stream. |
oslc_config:branch | Zero-or-one | true | Resource | Either | Unspecified | An indicator of the intended purpose of the baseline. |
oslc_config:committed | Zero-or-one | true | dateTime | N/A | Unspecified | Date and time this configuration was committed as a baseline. |
oslc_config:committer | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | The entity that committed this configuration as a baseline. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
oslc_config:component | Exactly-one | true | Resource | Reference | oslc_config:Component | The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'. |
oslc_config:contribution | Zero-or-many | true | AnyResource | Inline | oslc_config:Contribution | A contribution to this baseline. The set of resource versions identified by this baseline is the union of the set determined by theoslc_config:selections resources and each of the sets of resource versions identified by the contributed baselines.The target MUST be of type oslc_config:Contribution [CONFIG-RES-24].Contribution resources MUST be returned inline with the baseline resource [CONFIG-RES-25].In the set of Contribution resources for a single parent baseline, there MUST be only one Contribution resource for a given contributed baseline [CONFIG-RES-26]. |
oslc_config:previousBaseline | Zero-or-many | true | Resource | Reference | oslc_config:Baseline | A reference to the immediately preceding baseline of the same stream. Multiple instances of this property imply the stream was merged from one or more baselines before this baseline was taken.This property MAY be updated by the server to refer to earlier baselines when intermediate baselines are deleted [CONFIG-RES-27]. |
oslc_config:selections | Zero-or-many | true | Resource | Reference | oslc_config:Selections | A reference to a resource identifying immutable versions of the resources (configuration items) in the configuration. The set of version resources identified is the union of the sets in all the selections resources. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties;servers MAY treat such multiple occurrences of selections as an error [CONFIG-RES-28]. |
oslc_config:streams | Exactly-one | true | Resource | Reference | ldp:Container | The Linked Data Platform Containerthat contains all the streams derived from this baseline. A new stream derived from this baseline is created by a POST to this container;a previousBaseline property of the new stream MUST be set to refer to this baseline [CONFIG-RES-29]. Note that the streams property itself is immutable, but the container referenced by the property is not.The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-30].If a container resource shape is specified, it should have a property describing the membership of the container with a `oslc:valueShape` referencing a resource shape that describes the shapes of streams that may be created [CONFIG-RES-31]. |
oslc:archived | Zero-or-one | unspecified | boolean | N/A | Unspecified | Indicates whether the subject has been marked as archived, no longer an active resource. |
oslc:instanceShape | Zero-or-one | true | Resource | Either | oslc:ResourceShape | The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. Instance shapes may be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource, and other factors, so instance shapes SHOULD NOT be cached [CONFIG-RES-32]. |
oslc:modifiedBy | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | The entity that most recently modified the subject resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
oslc:release | Zero-or-many | false | Resource | Reference | Unspecified | A link to a resource indicating a target release for the artifacts selected by this configuration. |
oslc:serviceProvider | Zero-or-many | true | Resource | Reference | oslc:ServiceProvider | A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property. |
oslc:shortId | Zero-or-one | unspecified | string | N/A | Unspecified | A short and human-readable identifier for the resource, such as a number. |
oslc:shortTitle | Zero-or-one | unspecified | XMLLiteral | N/A | Unspecified | A short title for the resource, represented as rich text in XHTML content. |
prov:wasDerivedFrom | Zero-or-many | true | Resource | Reference | oslc_config:Configuration | A stream or baseline from which this stream was first copied. This property can be absent for streams created as new empty streams. Multiple instances of this property imply the stream was initially formed from a merge from one or more baselines.The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream [CONFIG-RES-33]. If this property is present on multiple change sets overriding the same base configuration, it implies a partial ordering of those change sets, identifying change sets derived from earlier change sets on the same base.Servers SHOULD treat this property as read-only after initial creation [CONFIG-RES-34]. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI.A baseline MUST have at least the resource type oslc_config:Baseline [CONFIG-RES-35]. Clients can infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation.Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties [CONFIG-RES-36]to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution.Servers MAY treat the rdf:type property of a baseline as read-only [CONFIG-RES-37]. |
3.3 Resource shape for Stream
- Describes:
http://open-services.net/ns/config#Stream
- Summary: The shape of a stream. Stream Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:contributor | Zero-or-many | unspecified | AnyResource | Either | foaf:Agent, foaf:Person | Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:created | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-38]. |
dcterms:creator | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:description | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Descriptive text about the resource, represented as rich text in XHTML content. |
dcterms:identifier | Zero-or-one | true | string | N/A | Unspecified | A unique identifier for this resource. |
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-39]. |
dcterms:subject | Zero-or-many | false | string | N/A | Unspecified | Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. |
dcterms:title | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Title of the resource, represented as rich text in XHTML content. |
oslc_config:acceptedBy | Zero-or-many | true | Resource | Reference | rdfs:Class | A type of configuration that accepts this configuration as a contribution.A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-40] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare. |
oslc_config:accepts | Zero-or-many | true | Resource | Reference | rdfs:Class | A type of configuration that is acceptable as a contribution to this stream. A configuration with no value for this predicate accepts no contributions - that is, it can only be a leaf in a configuration hierarchy. |
oslc_config:baselines | Exactly-one | true | Resource | Reference | ldp:Container | The Linked Data Platform Containerthat contains all the baselines of this stream. A new baseline of this stream is created by a POST to this container. Note that the baselines property itself is immutable, but the container referenced by the property is not.The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container [CONFIG-RES-41].If a container resource shape is specified, it SHOULD have a property describing the membership of the container with aoslc:valueShape referencing a resource shape that describes the additional properties that may be specified for baselines [CONFIG-RES-42]. |
oslc_config:branch | Zero-or-one | false | Resource | Either | Unspecified | An indicator of the intended purpose of the configuration. |
oslc_config:component | Exactly-one | true | Resource | Reference | oslc_config:Component | The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'. |
oslc_config:contribution | Zero-or-many | false | AnyResource | Inline | oslc_config:Contribution | A contribution to this configuration. The set of resource versions identified by this configuration is the union of the set determined by theoslc_config:selections resources and each of the sets of resource versions identified by the contributed configurations. A user can request an update to a configuration to change the set of contributions;servers MAY deny such requests if any added contributions do not match this configuration [CONFIG-RES-43].The target MUST be of type oslc_config:Contribution [CONFIG-RES-44].Contribution resources MUST be returned inline with the configuration resource [CONFIG-RES-45]. In the set of Contribution resources for a single parent configuration,there MUST be only one Contribution resource for a given contributed configuration [CONFIG-RES-46]. |
oslc_config:previousBaseline | Zero-or-many | true | Resource | Reference | oslc_config:Baseline | A reference to the immediately preceding baseline of this stream. Multiple instances of this property imply the stream was merged from one or more baselines, and no baseline of the merged result has yet been taken. If the property is absent, no baseline of this stream has been taken. |
oslc_config:selections | Zero-or-many | unspecified | Resource | Reference | oslc_config:Selections | A reference to a resource identifying versions of the resources (configuration items) in the configuration. The set of version resources identified is the union of the sets in all the selections resources. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties;servers MAY treat such multiple occurrences of selections as an error [CONFIG-RES-47].Servers MAY treat this property as read-only [CONFIG-RES-48]. |
oslc:archived | Zero-or-one | unspecified | boolean | N/A | Unspecified | Indicates whether the subject has been marked as archived, no longer an active resource. |
oslc:instanceShape | Zero-or-one | true | Resource | Either | oslc:ResourceShape | The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. Instance shapes may be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource, and other factors, so instance shapes SHOULD NOT be cached [CONFIG-RES-49]. |
oslc:modifiedBy | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | The entity that most recently modified the subject resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
oslc:release | Zero-or-many | false | Resource | Reference | Unspecified | A link to a resource indicating a target release for the artifacts selected by this configuration. |
oslc:serviceProvider | Zero-or-many | true | Resource | Reference | oslc:ServiceProvider | A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property. |
oslc:shortId | Zero-or-one | unspecified | string | N/A | Unspecified | A short and human-readable identifier for the resource, such as a number. |
oslc:shortTitle | Zero-or-one | unspecified | XMLLiteral | N/A | Unspecified | A short title for the resource, represented as rich text in XHTML content. |
prov:wasDerivedFrom | Zero-or-many | true | Resource | Reference | oslc_config:Configuration | A stream or baseline from which this stream was first copied. This property can be absent for streams created as new empty streams. Multiple instances of this property imply the stream was initially formed from a merge from one or more baselines.The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream [CONFIG-RES-50]. If this property is present on multiple change sets overriding the same base configuration, it implies a partial ordering of those change sets, identifying change sets derived from earlier change sets on the same base.Servers SHOULD treat this property as read-only after initial creation [CONFIG-RES-51]. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI.A stream MUST have at least the resource type oslc_config:Stream [CONFIG-RES-52]. Clients can infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation.Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution [CONFIG-RES-53].Servers MAY treat this property as read-only [CONFIG-RES-54]. |
3.4 Resource shape for ChangeSet
- Describes:
http://open-services.net/ns/config#ChangeSet
- Summary: The shape of a ChangeSet.
- Description: A ChangeSet is a mutable configuration (a type of stream) that replaces, or identifies a set of changes from, the configuration identified by the
oslc_config:overrides
property. That overridden configuration may be either a stream or a baseline, but a change set itself may not be a baseline.Servers MAY refuse to construct a baseline of a change set configuration [CONFIG-RES-55]. This specification does not define the meaning of one change set overriding another change set; servers MAY treat this as an error [CONFIG-RES-56]. If this change set has any contributions, those contributions completely replace the contributions to the overridden configuration when using this change set configuration as a context for resolving versions, or any configuration that contains this change set as a contribution; if this change set has no contributions, any contributions to the overridden configuration are handled normally. Selections in the change set may add to, replace, or remove from, the selections in the overridden configuration, as defined in ChangeSet Selections. ChangeSet Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:contributor | Zero-or-many | unspecified | AnyResource | Either | foaf:Agent, foaf:Person | Contributor or contributors to the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:created | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-57]. |
dcterms:creator | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:description | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Descriptive text about the resource, represented as rich text in XHTML content. |
dcterms:identifier | Zero-or-one | true | string | N/A | Unspecified | A unique identifier for this resource. |
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-58]. |
dcterms:subject | Zero-or-many | false | string | N/A | Unspecified | Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. |
dcterms:title | Zero-or-one | false | XMLLiteral | N/A | Unspecified | Title of the resource, represented as rich text in XHTML content. |
oslc_config:acceptedBy | Zero-or-many | true | Resource | Reference | rdfs:Class | A type of configuration that accepts this configuration as a contribution.A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration [CONFIG-RES-59] - that is, it can only be a root of a configuration hierarchy (or a stand-alone configuration if there is also no value for oslc_config:accepts). Such configurations should be rare. |
oslc_config:accepts | Zero-or-many | true | Resource | Reference | rdfs:Class | A type of configuration that is acceptable as a contribution to this stream. A configuration with no value for this predicate accepts no contributions - that is, it can only be a leaf in a configuration hierarchy. |
oslc_config:branch | Zero-or-one | false | Resource | Either | Unspecified | An indicator of the intended purpose of the configuration. |
oslc_config:component | Exactly-one | true | Resource | Reference | oslc_config:Component | The component of which this is a configuration, and from which the configuration selects versions of resources in the component. The component is an invariant relating the different configurations of the same 'thing'. |
oslc_config:contribution | Zero-or-many | unspecified | AnyResource | Inline | oslc_config:Contribution | A contribution to this change set configuration.Servers MAY support contributions to change sets [CONFIG-RES-60], and if so, this property behaves just as that for streams. |
oslc_config:overrides | Exactly-one | unspecified | Resource | Reference | oslc_config:Configuration | A reference to a configuration modified or overridden by this change set configuration. |
oslc_config:selections | Zero-or-many | unspecified | Resource | Reference | oslc_config:ChangeSetSelections | A reference to a resource identifying versions of the resources (configuration items) in the configuration; these selections override, reduce, or extend the selections in the configuration identified by the oslc_config:overrides property.Servers MAY treat this property as read-only [CONFIG-RES-61]. |
oslc:archived | Zero-or-one | unspecified | boolean | N/A | Unspecified | Indicates whether the subject has been marked as archived, no longer an active resource. |
oslc:instanceShape | Zero-or-one | true | Resource | Either | oslc:ResourceShape | The URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. Instance shapes may be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource, and other factors, so instance shapes SHOULD NOT be cached [CONFIG-RES-62]. |
oslc:modifiedBy | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | The entity that most recently modified the subject resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
oslc:release | Zero-or-many | false | Resource | Reference | Unspecified | A link to a resource indicating a target release for the artifacts selected by this configuration. |
oslc:serviceProvider | Zero-or-many | true | Resource | Reference | oslc:ServiceProvider | A link to the resource's OSLC Service Provider. If the subject resource is available from an application that implements multiple domain specifications, there can be multiple values for this property. |
oslc:shortId | Zero-or-one | unspecified | string | N/A | Unspecified | A short and human-readable identifier for the resource, such as a number. |
oslc:shortTitle | Zero-or-one | unspecified | XMLLiteral | N/A | Unspecified | A short title for the resource, represented as rich text in XHTML content. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI.A change set configuration MUST have at least the resource type oslc_config:ChangeSet [CONFIG-RES-63]. Clients may infer a resource type of oslc_config:Configuration, but there is no requirement for servers to materialize this triple in the RDF representation. Other types may be added, including types that are used in oslc_config:accepts properties to define which matching configurations to which this configuration may be added as a contribution.Servers MAY treat this property as read-only [CONFIG-RES-64]. |
3.5 Resource shape for Contribution
- Describes:
http://open-services.net/ns/config#Contribution
- Summary: A contribution to a configuration. Contribution Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of latest resource modification. Each resource SHOULD have one instance of the dcterms:modified property [CONFIG-RES-65]. |
oslc_config:configuration | Exactly-one | unspecified | Resource | Reference | oslc_config:Configuration | The contributed configuration. This property is read-only for contributions to a baseline, and modifiable for contributions to a stream.On a PUT or POST of a Stream resource and its Contributions, this contributed configuration SHOULD be unique amongst the set of configurations contributed to a given parent configuration [CONFIG-RES-66].a server MAY collapse multiple contributions for the same configuration to a single contribution [CONFIG-RES-67]. During such a reduction of multiple Contribution resources to a single Contribution resource, this specification does not define the contributionOrder value in the merged result. |
oslc_config:contributionOrder | Exactly-one | unspecified | string | N/A | Unspecified | An indication of the order of the contribution, relative to other contributions. Contributions are sorted lexicographically on the Unicode code points of this value to resolve component skew. To ensure predictable sorting regardless of implementation and locale, the oslc_config:contributionOrder string SHOULD be restricted to ASCII characters [CONFIG-RES-68].Servers MUST support at least 64 characters in this string [CONFIG-RES-69]. This property is read-only for contributions to a baseline, and modifiable for contributions to a stream. |
oslc_config:overrides | Exactly-one | unspecified | Resource | Reference | oslc_config:Configuration | A reference to a configuration overridden by the configuration of this contribution. |
rdf:type | Zero-or-many | true | Resource | Reference | rdfs:Class | A resource type URI. Clients can infer a resource type of oslc_config:Contribution, but there is no requirement for servers to materialize this triple in the RDF representation. |
3.6 Resource shape for Selections
- Describes:
http://open-services.net/ns/config#Selections
- Summary: The resources selected by a configuration. Selections Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
oslc_config:selects | Zero-or-many | unspecified | Resource | Reference | Unspecified | If the selection type is not oslc_config:UnboundSelections, the target resource MUST be a version resource [CONFIG-RES-70]. If the selection type is oslc_config:UnboundSelections, the target is a concept URI for a concept resource that should be in the configuration, but for which no version is determined by this selection. Unbound selections can be bound to specific versions by mechanisms not defined by this specification (such as effectivity parameters, variability parameters, etc.), or may be left unbound, in which case the configuration may represent an incomplete or abstract view of a system.Selected resources MUST NOT be of type oslc_config:Configuration [CONFIG-RES-71]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a selected resource of type oslc_config:Component.This property is read-only for selections of a baseline, but MAY be modifiable for selections of a stream [CONFIG-RES-72]. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI.A Selections resource MUST have at least the resource type oslc_config:Selections [CONFIG-RES-73].Selections resources MAY also have the type oslc_config:UnboundSelections [CONFIG-RES-74]. |
3.7 Resource shape for ChangeSet Selections
- Describes:
http://open-services.net/ns/config#ChangeSetSelections
- Summary: The resources selected by a change set. ChangeSetSelections Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
oslc_config:selects | Zero-or-many | unspecified | Resource | Reference | Unspecified | A selected version resource.Selected resources MUST NOT be of type oslc_config:Configuration [CONFIG-RES-75]; sub-configurations are given in the oslc_config:contributions property. No meaning is assigned to a selected resource of type oslc_config:Component.This property MAY be modifiable for selections of a change set [CONFIG-RES-76]. If the subject has the type oslc_config:RemoveAll, all selections in the overriden configuration are to be ignored; all selections are in this and other oslc_selects properties of the change set. Any target concept or version resources (depending on the presence or absence of the type oslc_config:UnboundSelections) indicated in this selection resource are selected in this configuration. Otherwise, if the subject has the type oslc_config:Removals, the indicated target concepts or versions are explicitly removed from the set of versions selected by the configuration overridden by this configuration. Otherwise, if the subject has only the type oslc_config:Selections, the indicated target concept or version resources are selected by this configuration; a change set selection overrides (replaces) the concepts or versions selected by a matching concept resource in the overridden configuration's selection, and adds additional selections for concept resources that are not mentioned in the overridden configuration's selection. Since selections properties are not ordered, there is no defined meaning to a selection that appears in two or more different selections properties of any types, or to a change set that include both a oslc_config:RemoveAll and a oslc_config:Removals selection;servers MAY treat occurrences of potentially conflicting selections as an error [CONFIG-RES-77]. |
rdf:type | One-or-many | unspecified | Resource | Reference | rdfs:Class | A resource type URI.A change set Selections resource MUST have at least the resource type oslc_config:Selections [CONFIG-RES-78].Change set selections resources MAY also have the types oslc_config:ChangeSetSelections,oslc_config:UnboundSelections, oslc_config:Removals, or oslc_config:RemoveAll [CONFIG-RES-79]. |
4. Configuration context
Since concept resource URIs for versioned resources do not inherently identify a specific version of that resource,a client SHOULD provide a configuration context within which the concept resource is resolved to a specific version [CONFIG-RES-80].
A client requests a specific configuration context in one of two ways:
- When performing a GET on a concept URI, add a
Configuration-Context
header, passing the URI of a configuration resource as the value.
Example 1
GET /resources/conceptResourceA HTTP/1.1
Configuration-Context: https://example.com/configurations/myConfiguration1 - When performing a GET on a concept URI, add a query string
oslc_config.context
and the encoded configuration URI to the end of the request URI:
Example 2
GET /resources/conceptResourceA?oslc_config.context=%3Chttp%3A//example.com/configurations/myConfiguration1%3E HTTP/1.1
Syntax of the query string for configuration context:
?oslc_config.context=urirefesc
The uri_ref_esc is an angle bracket-delimited URI reference in which > and \ are \-escaped, as defined in [OSLCCore3].
A server MUST support both these methods of passing configuration context. [CONFIG-RES-82]
If a request contains both a header and a query string, the server MUST use the query string. Servers MUST reject requests that contain two or more different configuration contexts passed in query strings.[CONFIG-RES-83]
A request SHOULD contain only a single occurrence of the Configuration-Context
header, and MUST NOT contain multiple Configuration-Context
headers referencing different values. A server SHOULD treat multiple identical Configuration-Context
headers as it would a single header, and MUST treat multiple Configuration-Context
headers with different configuration values as an error.[CONFIG-RES-86]
If a configuration context is passed on a request for a non-versioned resource, the server MUST NOT treat that as an error, and MAY use that context to resolve references to embedded or related resources.[CONFIG-RES-87]
If a configuration context is passed on a request using the version URI for a versioned resource, a server MUST ignore the configuration context, even if that configuration context does not select that versioned resource.[CONFIG-RES-88]
Note
The client is responsible for providing the correct configuration context to each request issued by that client at least where the relevant resource might be a versioned resource. If a resource returned from such a request contains links, the client should not assume the server has returned version-specific or configuration-specific links, and the client should continue to provide the correct configuration context to fetch those related resources. Only in cases where the client knows that a resource is not versioned may the configuration context be omitted. As noted later, the compact rendering returned for UI Previews is an exception to this rule.
Note: Implicitly defined configuration contexts
While navigating between resources, resources or links of certain types may indicate that a different context is to be used when following links from that resource. Any such semantics should be defined by the specifications for such resource and link types; none are defined by this specification.
4.1 Default configuration
If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail.[CONFIG-RES-89]
A server MAY include an oslc_config:configurationSettings
link in the OSLC Service resource, referencing an oslc_config:ConfigurationsSettings
resource. That resource MAY contain at most oneoslc_config:defaultConfiguration
property whose value is the URI of the default configuration to be used by that service.[CONFIG-RES-90]
An oslc_config:defaultConfiguration
property with an rdf:nil
value implies there is no default configuration, so requests with no context MUST fail.[CONFIG-RES-91]
Servers MAY support a PUT on oslc_config:ConfigurationsSettings
resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration.[CONFIG-RES-92]
Note: Default configuration may be implicit
The absence of the oslc_config:defaultConfiguration
has no implication as to the presence or absence of a default configuration.
5. Supported Operations on Components
A configuration server MUST support the following operations on components: [CONFIG-RES-93]
- HEAD and OPTIONS: Retrieve information about the component
- GET: Retrieve the current state of the component
- GET on the component creation factory LDPC to find all components
- GET on the configuration LDPC for a component to find all configurations (baselines and streams) of that component
A configuration server SHOULD support, and a global configuration server MUST support, the following operations on Linked Data Platform Containers:[CONFIG-RES-94]
Example 3
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"
allowing a client to retrieve properties about the LDPC, including anyoslc:resourceShape
properties, without needing to retrieve all membership triples.
Servers MAY support OSLC selective properties on a GET, allowing a client to specify exactly which properties of those LDPCs are to be returned.[CONFIG-RES-98]
A configuration server SHOULD support, and a global configuration server MUST support one or more component creation factories declared in one or more OSLC service providers.[CONFIG-RES-99]
A configuration server SHOULD support one or more query capabilities for components.[CONFIG-RES-100]
6. Supported Operations on Configurations
A configuration server MUST support the following operations on configurations: [CONFIG-RES-101]
- HEAD and OPTIONS: Retrieve information about the configuration
- GET: Retrieve the current state of the configuration
A configuration server SHOULD support, and a global configuration server MUST support, the following operations on configurations:[CONFIG-RES-102]
- PUT on a configuration resource to update the tags
- PUT on a configuration resource and its inline Contribution resources to update the set of contributed configurations
- DELETE a configuration;servers MAY refuse to delete configurations that are part of or referenced by existing baselines [CONFIG-RES-103].
A configuration server MAY support PATCH on a configuration to update the tags and/or the set of contributed configurations.[CONFIG-RES-104]
Since baselines are normally linked into a provenance chain using theoslc_config:previousBaseline
property,servers MAY leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline [CONFIG-RES-105].Servers SHOULD add the property oslc:archived=TRUE
on a reduced form of a partially deleted baseline [CONFIG-RES-106].
A configuration server SHOULD support one or more query capabilities for configurations.[CONFIG-RES-107]
7. Supported Operations on Selections
A configuration server MUST support the following operations on selections resources: [CONFIG-RES-108]
- HEAD and OPTIONS: Retrieve information about a selections resource
- GET: Retrieve the current state of a selections resource
Note
Servers may treat selections resources as read-only.
8. Supported Operations on Versioned Resources in a Configuration Context
A configuration server MUST support the following operations on configuration items (versioned concept resources) in the context of a global configuration, or in the context of a configuration from this server:[CONFIG-RES-109]
- HEAD: Retrieve information including the version resource URI (if any) about the state of a specified versioned concept resource in the context of a specified configuration.
- GET: Retrieve the state of a specified versioned concept resource in the context of a specified configuration, where this operation returns zero or one version resources matching the required state.An attempt to GET a version resource URI in a configuration context where a different version of that concept resource MUST ignore the configuration context and return the specified version resource if it exists. [CONFIG-RES-110].
- PUT: Update the state of a specified versioned concept resource in a specified stream or change set;this operation MAY cause the creation of a new version of the resource [CONFIG-RES-111].
A configuration server MAY support the following operations on configuration items in the context of a global configuration, or in the context of a configuration from this server:[CONFIG-RES-112]
- DELETE: Delete the current mutable version resource in a specified stream or change set.
9. Creation of Baselines and Streams
When a new component is created by POSTing to the Component Container, an empty baseline for that component_SHOULD_ be created automatically, and MUST be added to the oslc_config:configurations
container for that component. The empty baseline has no contributions, no selections, and no branch.[CONFIG-RES-114]
9.1 Creation of Streams
A new stream is created by POSTing to the oslc_config:streams
container for a baseline. By default, the new stream inherits (MUST copy) the component, contributions, and selections of the baseline, but does not inherit (MUST NOT copy) the branch property. Other properties MAY be inherited (copied) from the baseline, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values:[CONFIG-RES-115]
dcterms:subject
dcterms:title
*dcterms:description
oslc:shortTitle
*oslc_config:branch
oslc_config:contribution
oslc_config:selections
The server MUST set the oslc_config:previousBaseline
property of the new stream, and SHOULD set the prov:wasDerivedFrom
property of the new stream, to reference the baseline owning theoslc_config:streams
container.[CONFIG-RES-116]
A server MAY support one or more configuration creation factories declared in one or more OSLC service providers that create a stream for the component specified in the configuration's POSTED RDF body.[CONFIG-RES-117]
9.2 Creation of Baselines
A new baseline of a stream is created by POSTing to the oslc_config:baselines
container for that stream. If the server determines that a suitable baseline already exists, the server MAY return a 303 with aLocation
header referring to that existing baseline; for an existing baseline to be suitable it_MUST_ be for the same component, MUST have the same oslc_config:branch
value, if any, MUST select the same version resources, each contribution MUST be a suitable baseline for the corresponding stream contribution, and there must be no additional or missing contributions.[CONFIG-RES-118]
Where a new baseline is created, that new baseline inherits (MUST copy) the following properties of the stream:[CONFIG-RES-119]
oslc_config:branch
oslc_config:component
oslc_config:contribution
oslc_config:selections
oslc_config:previousBaseline
Other properties MAY be inherited (copied) from the stream, or MAY be set to server defaults. The POSTed data_MAY_ include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values:[CONFIG-RES-120]
dcterms:subject
dcterms:title *
dcterms:description
oslc:shortTitle *
When creating a new baseline from a stream, after copying all previous values of thepreviousBaseline
to the new baseline, the server MUST replace all thosepreviousBaseline
properties on the stream by a single reference to the newly created baseline. The chain of previousBaseline
links thus shows the history of baselines of a stream.[CONFIG-RES-121]
The server MUST set the oslc_config:baselineOfStream
property of the new baseline to reference the stream owning the oslc_config:baselines
container.[CONFIG-RES-122]
Since all contributions to a baseline must themselves be baselines, creation of a baseline requires that a server MUST first create or obtain baselines for the current state of all stream contributions, recursively downward through the contribution graph. See Long Operations.[CONFIG-RES-123]
9.3 Concerns common to streams and baselines
* A server MAY adjust the name properties of a configuration to maintain any name uniqueness constraints; a server SHOULD NOT fail creation of a baseline or stream just because the requested name is not unique.[CONFIG-RES-124]
The server MAY ignore any additional properties, or MAY return an error if those properties are considered incompatible with the creation request.[CONFIG-RES-125]
Any properties required on new streams or baselines not defined by this standard MUST be described in resource shapes referenced by oslc:resourceShape
properties on the container.[CONFIG-RES-126]
Example 4
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"
allowing a client to retrieve properties about the LDPC, including anyoslc:resourceShape
properties, without needing to retrieve all membership triples.Servers MAY support OSLC selective properties on a GET [CONFIG-RES-128], allowing a client to specify exactly which properties of those LDPCs are to be returned.
10. Contributions and Overrides
Global configurations, and possible other types of configuration, support aggregation of multiple configurations, using the oslc_config:Contribution
resource. Changes to contributions are made using PUT. For change sets, and possibly other use cases, a configuration or contribution can override another configuration contributed to the overall hierarchy. An override relationship may be specified at the configuration level (for change sets that apply to a specific base configuration) or at the contribution level (allowing a hierarchy where some contributions may override others without modifying the properties of potentially shared configurations).
- When adding a contribution, if the configuration being added has an
oslc_config:overrides
relationship, that relationship MUST be copied to the contribution.[CONFIG-RES-129] - If the configuration being added has no OSLC overrides - it is a reusable configuration - a client MAY include an
oslc_config:overrides
relationship in a PUT to the contribution resource.[CONFIG-RES-130] - Servers MAY require an overriding configuration to be for the same component as the overridden contribution.[CONFIG-RES-131]
- Servers MAY report an error if the configuration identified in the
oslc_config:overrides
property does not exist in the hierarchy for the context configuration.[CONFIG-RES-132]
11. Version Resolution
When a request is made for a versioned resource in the context of a configuration:
- if there is no version of that resource in any of the selections in the contributions to the context configuration, nor in any of the selections in their recursive contributions, the request MUST fail with a 404 Resource not found (note that this includes unbound selections from a selection with type
oslc_config:UnboundSelections
)[CONFIG-RES-133] - if there is exactly one version of that resource in the union of the selections in the recursive contributions, the request MUST return that one version[CONFIG-RES-134]
- if there is more than one version of that resource in the union of the selections in the recursive contributions,the behavior is implementation-defined, but SHOULD be well-defined in that the successive requests in the same configurations with the same selections SHOULD resolve to the same version. A server MAY perform an ordered search using the
oslc_config:contributionOrder
property, and MAY have a way to indicate multiple possible version resolutions [CONFIG-RES-135].
Note
Theoslc_config:contributionOrder
property is defined as a string rather than an integer to make it easier for servers to insert new contributions into an existing set without having to adjust the order value of existing contributions.
During this version resolution, overrides for entire configurations MUST be taken into account. If a contribution is marked as an override and the overriding configuration is earlier in the ordered set of all recursive contributions than the overridden configuration, the overridden configuration and all its contributions MUST be ignored in their entirety. Servers MAY report an error if an overriding configuration is later in the ordered set of all recursive contributions than the overridden configuration.[CONFIG-RES-136]
Overrides from change set configurations MUST also be taken into account. If a change set removes a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, then the request MUST fail with a 404 Resource not found. If a change set replaces a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, the request MUST return the version in the change set selection.[CONFIG-RES-137]
Implementations SHOULD provide documentation on their version resolution behavior. [CONFIG-RES-138]
12. Change Sets
This section is non-normative.
Some systems use change sets to group related changes, or changes to multiple resources that must be kept together. Change sets may be represented using a configuration of type oslc_config:ChangeSet
- a special type of stream. Each oslc_config:ChangeSet
resource is related to exactly one base configuration (either a stream or a baseline), using the oslc_config:overrides
property. Aoslc_config:ChangeSet
has either a complete set of replacements for the versions selected by that base configuration, or a set of changes - a delta. The configuration defined by a change set thus identifies both the 'before' state (the base configuration that is overridden by this change set), and the 'after' state defined by the change set configuration itself.
Systems that allow multiple change sets to be applied to a single base configuration should represent each such internal change set as an oslc_config:ChangeSet
resource using the same value ofoslc_config:overrides
; the property prov:wasDerivedFrom
should be used to provide a complete or partial ordering of such change sets. Servers may also synthesize a combinedoslc_config:ChangeSet
resource representing the overall effect of multiple internal change sets.
When a change set is based on a stream (the oslc_config:overrides
property on an instance of anoslc_config:ChangeSet
refers to a configuration of type oslc_config:Stream
), then the 'before' state is mutable, and may not represent the state at the time the change set was created. Servers can avoid this lack of precision by ensuring either that all changes made to a stream are captured in a change set based off that stream, or that the stream's oslc_config:selections
properties accurately represent the sets of changes delivered to that stream before any of the change sets based on that stream (those change sets probably representing changes still pending for the stream).
Since the shape for a change set allows only a single value for oslc_config:overrides
, systems that allow a single change set to be applied to multiple base configurations need to represent that internal change set by multiple oslc_config:ChangeSet
resources. These copies may be associated with each other using properties such as http://purl.org/datanode/ns#isCopyOf
, dcterms:relation
, or similar.
13. Delegated UIs
All configuration servers MUST provide a delegated user interface dialog for selection of configurations. A global configuration server MUST provide, and a local configuration server MAY provide, a delegated user interface dialog for creation of configurations.[CONFIG-RES-139]
In order to provide a good user experience when selecting configurations to be used as contributions to a parent configuration, the UI Consumer SHOULD provide the URI of the parent configuration as a parameter to the Delegated UI Dialog, using the parameter oslc_config.parentConfiguration
. UI Providers SHOULD use the types and oslc_config:accepts
property values of that resource to filter the list of potential contributions shown in the selection dialog.[CONFIG-RES-140]
Syntax:
?oslc_config.parentConfiguration=urirefesc
Example:
Example 5
?oslc_config.parentConfiguration=%3Chttps://example.com/configurations/globalConfig12%3E
Tools providing versioned resources using configuration management systems SHOULD provide delegated user interface dialogs for selection of versioned resources in the context of a configuration, and MAY provide delegated user interface dialogs for creation of versioned resources in the context of a configuration.[CONFIG-RES-141]
14. Compact Rendering
Configuration servers SHOULD implement [OSLCCore3] UI Previews and compact rendering.[CONFIG-RES-142]
Where implemented, clients MUST pass any required configuration context on the initial request for a compact resource, and the configuration server MUST return a compact resource honoring that configuration context.[CONFIG-RES-143]
Moreover, the icon reference, the large preview reference, the small preview reference, and any image or intra-page references directly embedded in the large and small HTML preview documents in that compact resource_MUST_ correspond to the given configuration context, so the client need not pass a configuration context to render the icon or the HTML preview.[CONFIG-RES-144]
A reference corresponds to a given configuration if it is the URI of a non-versioned resource, the version URI for a versioned resource selected by the given configuration, or a concept resource URI with a configuration query string that resolves to the versioned resource selected by the given configuration.
15. Tracked Resource Sets
A configuration server SHOULD provide one or more Tracked Resource Sets for configurations, contributions, and components. A configuration server MAY publish selections and versioned resources in a Tracked Resource Set (TRS); URIs for versioned resources in the base and change log of the TRS MUST be version resource URIs.[CONFIG-RES-145]
16. Query Support
Configuration servers MAY support [OSLCQuery] for configurations and components. If OSLC Query is provided, queries for the following properties using oslc.where
and oslc.select
SHOULD be supported:[CONFIG-RES-146]
dcterms:title
dcterms:created
dcterms:subject
rdf:type
oslc_config:component
oslc_config:contribution{oslc_config:configuration}
oslc_config:baselineOfStream
Query for other properties MAY be supported. [CONFIG-RES-147]
For example, this is a query for baselines of a given stream https://example.com/configs/stream123
, with tag 'stellar', created after July 1st 2014:
Example 6
https://example.com/configs?oslc.where=oslc_config:baselineOfStream=https://example.com/configs/stream123 and dc_terms:modified>="2014-07-01T00:00:00" and dcterms_subject="stellar"
Since some of those character must be encoded, the request would be issued as:
Example 7
https://example.com/configs?oslc.where=oslc_config%3AbaselineOfStream%3D%3Chttps%3A%2F%2Fexample.com%2Fconfigs%2Fstream123%3E%20and %20dc_terms%3Amodified%3E%3D%222014-07-01T00%3A00%3A00%22%20and%20dcterms_subject%3D%22stellar%22
Servers that support query capabilities on versioned resources MUST support the use of a configuration context to limit the query results to the versions selected by that configuration context, or to unversioned resources. The configuration context MUST support reference of a global configuration, or a configuration from this server.[CONFIG-RES-148]
17. Matching Contributions
Certain types of streams accept only certain other types of configurations as contributions.A global stream MUST accept any suitable configuration (baseline or stream) from an arbitrary configuration server [CONFIG-RES-149], while a stream from some non-global server might accept only configurations from the same server. For a non-global server, some configurations may be acceptable as contributions to global streams, while other non-global configurations are valid only as a contribution to a broader scoped stream from that same server.
The acceptability of a configuration as a child contribution to a parent stream is governed by theoslc_config:acceptedBy
property on the child configuration and theoslc_config:accepts
property on the parent stream. A configuration is a match, and thus acceptable as a contribution, if and only if:
- The parent has an
oslc_config:accepts
property whose value matches one of the types of the child configuration, AND - The child has an
oslc_config:acceptedBy
property whose value matches one of the types of the parent configuration.
A configuration type matches another type if they are the same type, or if the parent type isoslc_config:Configuration
and the child type is either oslc_config:Baseline
oroslc_config:Stream
. No other form of inference is required, butservers MAY use inference through properties such as owl:sameAs
andrdfs:subClassOf
to extend the definition of matching configuration types [CONFIG-RES-150].
A configuration is marked as a global configuration by adding an oslc_config:accepts
property with the value oslc_config:Configuration
.Any configuration that is suitable to be a contribution to a global configuration (including global configurations themselves) MUST have an oslc_config:acceptedBy
property with the valueoslc_config:Configuration
[CONFIG-RES-151]. A stream is marked as not accepting any kind of contribution (that is, it may only appear as a leaf in the configuration tree) by not having any oslc_config:accepts
property. A configuration is marked as ineligible as any form of contribution (that is, it may only appear as a root in the configuration tree) by not having any oslc_config:acceptedBy
property.
A stream with an oslc_config:accepts
property with the valueoslc_config:Baseline
accepts only baselines in changes to its set of contributions.A server MAY use this to indicate a stream being used to stage the progressive construction of a baseline [CONFIG-RES-152], where any initial stream contributions are gradually replaced by baselines as they become available.
Since baselines are immutable, their contributions (if any) are immutable, derived from the streams from which those baselines were created, so the oslc_config:accepts
property is not meaningful and may be omitted.
Configuration servers MAY define their own types of configuration, and use those types inoslc_config:acceptedBy
and oslc_config:accepts
properties to define the allowed contributions.[CONFIG-RES-153]
Servers MAY treat the oslc_config:accepts
and oslc_config:acceptedBy
as server-generated read-only properties, not modifiable by a client.[CONFIG-RES-154]
Servers MAY perform validation of oslc_config:accepts
code> and oslc_config:acceptedBy
. If a server performs such validation, it MAY limit validation to new contributions being added or defined for the first time.[CONFIG-RES-155]
18. Long Operations
Some operations (for example, creating a baseline from a large hierarchy of streams) can take a long time to complete.
Servers MAY use the standard HTTP response 202 Request Accepted to indicate that a request has been accepted, but may not yet be complete.[CONFIG-RES-156]
The content and location header of this 202 response MUST be that of anoslc_config:Activity
resource, indicating the progress or result of that activity. Clients SHOULD poll the Activity resource periodically until the state indicates it has finished.[CONFIG-RES-157]
Each Activity resource MUST be persisted by a server (including over a restart) for a minimum of 24 hours after completion of the long operation as a whole, or until explicitly deleted by a client.[CONFIG-RES-158]
Clients SHOULD delete each Activity created by a long-running operation soon after the client has seen the completion of the activity, or when the client is no longer interested in the result. Servers MAY deny clients access to delete Activity resources including but not limited to activities still in progress, or activities not created by that client, or MAY require clients to have a specific role or permission to delete activities.[CONFIG-RES-159]
- Describes:
http://open-services.net/ns/config#Activity
- Summary: The shape of an activity.
- Description: An activity is a read-only resource representing a long-running operation, such as recursive baseline or stream creation. Activity Properties
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description |
---|---|---|---|---|---|---|
dcterms:created | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of resource creation. Each resource SHOULD have one instance of the dcterms:created property [CONFIG-RES-160]. |
dcterms:creator | Zero-or-many | true | AnyResource | Either | foaf:Agent, foaf:Person | Creator or creators of the resource. The link target is usually a foaf:Person or foaf:Agent, but could be any type. |
dcterms:modified | Zero-or-one | true | dateTime | N/A | Unspecified | Timestamp of the last change of status. If this property is missing, the time of creation can be taken to be the same as the last change of status. |
dcterms:references | Zero-or-one | true | AnyResource | Either | Unspecified | A reference to a resource providing more details about the progress or result of the activity. For successful or partially successful operations, the dcterms:references property MUST be present, providing a link to the primary resource created or affected by the operation [CONFIG-RES-161]. For completely unsuccessful activities, this property may be missing.For activities still in progress, this MAY be a reference to a resource providing further information; which MAY be provided inline [CONFIG-RES-162]. |
dcterms:title | Exactly-one | true | XMLLiteral | N/A | Unspecified | A name for the activity, or current phase of the activity. |
oslc_auto:progress | Zero-or-one | true | integer | N/A | Unspecified | The percentage (0-100) of completion, if known. |
oslc_auto:state | Exactly-one | true | Resource | Reference | Unspecified | The state of the activity, as defined by OSLC Automation states. |
oslc_auto:verdict | Exactly-one | true | Resource | Reference | Unspecified | The result of the activity, as defined by OSLC Automation verdicts. |
oslc_config:progressMessage | Zero-or-one | true | XMLLiteral | N/A | Unspecified | Descriptive text about the progress of the activity, represented as rich text in XHTML content. |
oslc:error | Zero-or-many | true | AnyResource | Either | oslc:Error | A warning or error issued by the activity.Instances of this property MAY appear at any time during the execution of the activity, or MAY be returned only after the activity is complete [CONFIG-RES-163]. |
rdf:type | One-or-many | true | Resource | Reference | rdfs:Class | A resource type URI. An Activity MUST have a resource type of oslc_config:Activity, and MAY have other types [CONFIG-RES-164]. |
19. Conformance
Implementations of this specification need to satisfy the following conformance clauses.
Clause Number | Requirement |
---|---|
CONFIG-RES-1 | A configuration server SHOULD implement [OSLCCore3] ServiceProvider and Service resources, where anoslc:domain property has the value http://open-services.net/ns/config#. |
CONFIG-RES-2 | A global configuration service resource, if provided, SHOULD include the property oslc:usage with the value http://open-services.net/ns/config#globalConfigurationService. |
CONFIG-RES-3 | A service with this usage property MUST provide all global configuration capabilities described as mandatory in this specification. |
CONFIG-RES-4 | Configuration Management servers MUST observe these constraints, but MAY provide additional classes, properties, and individuals. |
CONFIG-RES-5 | In particular, Configuration Management servers MAY define additional types of configuration, but all configurations MUST also be of one of the types defined here. |
CONFIG-RES-6 | A component itself MAY be a versioned resource |
CONFIG-RES-7 | Each resource SHOULD have one instance of the dcterms:created property |
CONFIG-RES-8 | Each resource SHOULD have one instance of the dcterms:modified property |
CONFIG-RES-9 | The oslc_config:configurations property on a component is read-only; servers MAY also treat the referenced container as read-only |
CONFIG-RES-10 | the container MAY have an oslc:resourceShape property referencing a resource shape that describes the container |
CONFIG-RES-11 | If a container resource shape is specified, the shape SHOULD have a property describing the membership of the container with aoslc:valueShape referencing a resource shape that describes the shapes of streams and baselines that may be created |
CONFIG-RES-12 | instance shapes SHOULD NOT be cached |
CONFIG-RES-13 | A Component MUST have a resource type of oslc_config:Component |
CONFIG-RES-14 | A component MAY be a Linked Data Platform Container, containing the concept resources associated with this component |
CONFIG-RES-15 | The members of such an oslc_config:Component container MUST NOT be of type oslc_config:Configuration |
CONFIG-RES-16 | Servers MAY treat the rdf:type property for a component as read-only. |
CONFIG-RES-17 | Properties of a baseline defined in this specification MUST be read-only unless stated otherwise |
CONFIG-RES-18 | Each resource SHOULD have one instance of the dcterms:created property |
CONFIG-RES-19 | The description of a baseline MAY be modifiable |
CONFIG-RES-20 | Each resource SHOULD have one instance of the dcterms:modified property |
CONFIG-RES-21 | Tags on baselines MUST be modifiable |
CONFIG-RES-22 | The title of a baseline SHOULD be modifiable |
CONFIG-RES-23 | A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration |
CONFIG-RES-24 | The target MUST be of type oslc_config:Contribution |
CONFIG-RES-25 | Contribution resources MUST be returned inline with the baseline resource |
CONFIG-RES-26 | In the set of Contribution resources for a single parent baseline, there MUST be only one Contribution resource for a given contributed baseline |
CONFIG-RES-27 | This property MAY be updated by the server to refer to earlier baselines when intermediate baselines are deleted |
CONFIG-RES-28 | servers MAY treat such multiple occurrences of selections as an error |
CONFIG-RES-29 | a previousBaseline property of the new stream MUST be set to refer to this baseline |
CONFIG-RES-30 | The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container |
CONFIG-RES-31 | If a container resource shape is specified, it should have a property describing the membership of the container with a `oslc:valueShape` referencing a resource shape that describes the shapes of streams that may be created |
CONFIG-RES-32 | instance shapes SHOULD NOT be cached |
CONFIG-RES-33 | The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream |
CONFIG-RES-34 | Servers SHOULD treat this property as read-only after initial creation |
CONFIG-RES-35 | A baseline MUST have at least the resource type oslc_config:Baseline |
CONFIG-RES-36 | Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties |
CONFIG-RES-37 | Servers MAY treat the rdf:type property of a baseline as read-only |
CONFIG-RES-38 | Each resource SHOULD have one instance of the dcterms:created property |
CONFIG-RES-39 | Each resource SHOULD have one instance of the dcterms:modified property |
CONFIG-RES-40 | A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration |
CONFIG-RES-41 | The container MAY have an oslc:resourceShape property referencing a resource shape that describes the container |
CONFIG-RES-42 | If a container resource shape is specified, it SHOULD have a property describing the membership of the container with aoslc:valueShape referencing a resource shape that describes the additional properties that may be specified for baselines |
CONFIG-RES-43 | servers MAY deny such requests if any added contributions do not match this configuration |
CONFIG-RES-44 | The target MUST be of type oslc_config:Contribution |
CONFIG-RES-45 | Contribution resources MUST be returned inline with the configuration resource |
CONFIG-RES-46 | there MUST be only one Contribution resource for a given contributed configuration |
CONFIG-RES-47 | servers MAY treat such multiple occurrences of selections as an error |
CONFIG-RES-48 | Servers MAY treat this property as read-only |
CONFIG-RES-49 | instance shapes SHOULD NOT be cached |
CONFIG-RES-50 | The prov:wasDerivedFrom property is undefined for baselines; it MAY be absent, or it MAY have the same value as oslc_config:baselineOfStream |
CONFIG-RES-51 | Servers SHOULD treat this property as read-only after initial creation |
CONFIG-RES-52 | A stream MUST have at least the resource type oslc_config:Stream |
CONFIG-RES-53 | Other types MAY be added, including types that are used in oslc_config:accepts and oslc_config:acceptedBy properties to define which matching configurations may be added as contributions to this configuration, or to which this configuration may be added as a contribution |
CONFIG-RES-54 | Servers MAY treat this property as read-only |
CONFIG-RES-55 | Servers MAY refuse to construct a baseline of a change set configuration |
CONFIG-RES-56 | servers MAY treat this as an error |
CONFIG-RES-57 | Each resource SHOULD have one instance of the dcterms:created property |
CONFIG-RES-58 | Each resource SHOULD have one instance of the dcterms:modified property |
CONFIG-RES-59 | A configuration with no value for oslc_config:acceptedBy MUST NOT be used as a contribution to any other configuration |
CONFIG-RES-60 | Servers MAY support contributions to change sets |
CONFIG-RES-61 | Servers MAY treat this property as read-only |
CONFIG-RES-62 | instance shapes SHOULD NOT be cached |
CONFIG-RES-63 | A change set configuration MUST have at least the resource type oslc_config:ChangeSet |
CONFIG-RES-64 | Servers MAY treat this property as read-only |
CONFIG-RES-65 | Each resource SHOULD have one instance of the dcterms:modified property |
CONFIG-RES-66 | On a PUT or POST of a Stream resource and its Contributions, this contributed configuration SHOULD be unique amongst the set of configurations contributed to a given parent configuration |
CONFIG-RES-67 | a server MAY collapse multiple contributions for the same configuration to a single contribution |
CONFIG-RES-68 | the oslc_config:contributionOrder string SHOULD be restricted to ASCII characters |
CONFIG-RES-69 | Servers MUST support at least 64 characters in this string |
CONFIG-RES-70 | If the selection type is not oslc_config:UnboundSelections, the target resource MUST be a version resource |
CONFIG-RES-71 | Selected resources MUST NOT be of type oslc_config:Configuration |
CONFIG-RES-72 | This property is read-only for selections of a baseline, but MAY be modifiable for selections of a stream |
CONFIG-RES-73 | A Selections resource MUST have at least the resource type oslc_config:Selections |
CONFIG-RES-74 | Selections resources MAY also have the type oslc_config:UnboundSelections |
CONFIG-RES-75 | Selected resources MUST NOT be of type oslc_config:Configuration |
CONFIG-RES-76 | This property MAY be modifiable for selections of a change set |
CONFIG-RES-77 | servers MAY treat occurrences of potentially conflicting selections as an error |
CONFIG-RES-78 | A change set Selections resource MUST have at least the resource type oslc_config:Selections |
CONFIG-RES-79 | Change set selections resources MAY also have the types oslc_config:ChangeSetSelections,oslc_config:UnboundSelections, oslc_config:Removals, or oslc_config:RemoveAll |
CONFIG-RES-80 | a client SHOULD provide a configuration context within which the concept resource is resolved to a specific version |
CONFIG-RES-81 | The Configuration-Context header is a URI that MUST conform to the following ABNF grammar [ABNF]: SP = " " HTAB = %x09 WSP = SP / HTAB header = config-context config-context = "Configuration-Context:" *WSP URI Where the term URI is defined in [URI]. |
CONFIG-RES-82 | A server MUST support both these methods of passing configuration context. |
CONFIG-RES-83 | If a request contains both a header and a query string, the server MUST use the query string. Servers MUST reject requests that contain two or more different configuration contexts passed in query strings. |
CONFIG-RES-84 | Where the Configuration-Context header is used on a request, a server SHOULD include in the response a header Vary=Configuration-Context so that different configuration contexts do not use a previously cached response. |
CONFIG-RES-85 | Configuration Management servers SHOULD use the Access-Control-Allow-Headers header [CORS] to allow the use of the Configuration-Context header in OSLC requests. |
CONFIG-RES-86 | A request SHOULD contain only a single occurrence of the Configuration-Context header, and MUST NOT contain multiple Configuration-Context headers referencing different values. A server SHOULD treat multiple identical Configuration-Context headers as it would a single header, and MUST treat multiple Configuration-Context headers with different configuration values as an error. |
CONFIG-RES-87 | If a configuration context is passed on a request for a non-versioned resource, the server MUST NOT treat that as an error, and MAY use that context to resolve references to embedded or related resources. |
CONFIG-RES-88 | If a configuration context is passed on a request using the version URI for a versioned resource, a server MUST ignore the configuration context, even if that configuration context does not select that versioned resource. |
CONFIG-RES-89 | If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail. |
CONFIG-RES-90 | A server MAY include an oslc_config:configurationSettings link in the OSLC Service resource, referencing an oslc_config:ConfigurationsSettings resource. That resource MAY contain at most oneoslc_config:defaultConfiguration property whose value is the URI of the default configuration to be used by that service. |
CONFIG-RES-91 | An oslc_config:defaultConfiguration property with an rdf:nil value implies there is no default configuration, so requests with no context MUST fail. |
CONFIG-RES-92 | Servers MAY support a PUT on oslc_config:ConfigurationsSettings resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration. |
CONFIG-RES-93 | A configuration server MUST support the following operations on components: |
CONFIG-RES-94 | A configuration server SHOULD support, and a global configuration server MUST support, the following operations on Linked Data Platform Containers: |
CONFIG-RES-95 | POST to the component LDPC to create a new component. A successful response MUST contain aLocation header providing the URI of the newly created component. |
CONFIG-RES-96 | POST to the configuration LDPC for a component to create a new stream for that component, optionally specifying an initial baseline; if an initial baseline is not specified, a real or notional empty baseline is implied as the starting point for the stream. A successful response MUST contain aLocation header providing the URI of the newly created component. |
CONFIG-RES-97 | Servers SHOULD support the Prefer header for GET on LDPCs specifying PreferMinimalContainer: |
CONFIG-RES-98 | Servers MAY support OSLC selective properties on a GET, allowing a client to specify exactly which properties of those LDPCs are to be returned. |
CONFIG-RES-99 | A configuration server SHOULD support, and a global configuration server MUST support one or more component creation factories declared in one or more OSLC service providers. |
CONFIG-RES-100 | A configuration server SHOULD support one or more query capabilities for components. |
CONFIG-RES-101 | A configuration server MUST support the following operations on configurations: |
CONFIG-RES-102 | A configuration server SHOULD support, and a global configuration server MUST support, the following operations on configurations: |
CONFIG-RES-103 | servers MAY refuse to delete configurations that are part of or referenced by existing baselines |
CONFIG-RES-104 | A configuration server MAY support PATCH on a configuration to update the tags and/or the set of contributed configurations. |
CONFIG-RES-105 | servers MAY leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline |
CONFIG-RES-106 | Servers SHOULD add the property oslc:archived=TRUE on a reduced form of a partially deleted baseline |
CONFIG-RES-107 | A configuration server SHOULD support one or more query capabilities for configurations. |
CONFIG-RES-108 | A configuration server MUST support the following operations on selections resources: |
CONFIG-RES-109 | A configuration server MUST support the following operations on configuration items (versioned concept resources) in the context of a global configuration, or in the context of a configuration from this server: |
CONFIG-RES-110 | An attempt to GET a version resource URI in a configuration context where a different version of that concept resource MUST ignore the configuration context and return the specified version resource if it exists. |
CONFIG-RES-111 | this operation MAY cause the creation of a new version of the resource |
CONFIG-RES-112 | A configuration server MAY support the following operations on configuration items in the context of a global configuration, or in the context of a configuration from this server: |
CONFIG-RES-113 | POST to a component in the context of a stream or change set, resulting in the creation of the first version of a new concept resource, or a new version of an existing resource. A successful response MUST include aLocation header specifying the URI of the newly created resource. |
CONFIG-RES-114 | When a new component is created by POSTing to the Component Container, an empty baseline for that component_SHOULD_ be created automatically, and MUST be added to the oslc_config:configurations container for that component. The empty baseline has no contributions, no selections, and no branch. |
CONFIG-RES-115 | A new stream is created by POSTing to the oslc_config:streams container for a baseline. By default, the new stream inherits (MUST copy) the component, contributions, and selections of the baseline, but does not inherit (MUST NOT copy) the branch property. Other properties MAY be inherited (copied) from the baseline, or MAY be set to server defaults. The POSTed data MAY include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values: |
CONFIG-RES-116 | The server MUST set the oslc_config:previousBaseline property of the new stream, and SHOULD set the prov:wasDerivedFrom property of the new stream, to reference the baseline owning theoslc_config:streams container. |
CONFIG-RES-117 | A server MAY support one or more configuration creation factories declared in one or more OSLC service providers that create a stream for the component specified in the configuration's POSTED RDF body. |
CONFIG-RES-118 | A new baseline of a stream is created by POSTing to the oslc_config:baselines container for that stream. If the server determines that a suitable baseline already exists, the server MAY return a 303 with aLocation header referring to that existing baseline; for an existing baseline to be suitable it_MUST_ be for the same component, MUST have the same oslc_config:branch value, if any, MUST select the same version resources, each contribution MUST be a suitable baseline for the corresponding stream contribution, and there must be no additional or missing contributions. |
CONFIG-RES-119 | Where a new baseline is created, that new baseline inherits (MUST copy) the following properties of the stream: |
CONFIG-RES-120 | Other properties MAY be inherited (copied) from the stream, or MAY be set to server defaults. The POSTed data_MAY_ include any of the following properties; if these properties are supported by the server, then the POSTed values for these properties MUST completely replace any default or inherited values: |
CONFIG-RES-121 | When creating a new baseline from a stream, after copying all previous values of thepreviousBaseline to the new baseline, the server MUST replace all thosepreviousBaseline properties on the stream by a single reference to the newly created baseline. The chain of previousBaseline links thus shows the history of baselines of a stream. |
CONFIG-RES-122 | The server MUST set the oslc_config:baselineOfStream property of the new baseline to reference the stream owning the oslc_config:baselines container. |
CONFIG-RES-123 | Since all contributions to a baseline must themselves be baselines, creation of a baseline requires that a server MUST first create or obtain baselines for the current state of all stream contributions, recursively downward through the contribution graph. See Long Operations. |
CONFIG-RES-124 | * A server MAY adjust the name properties of a configuration to maintain any name uniqueness constraints; a server SHOULD NOT fail creation of a baseline or stream just because the requested name is not unique. |
CONFIG-RES-125 | The server MAY ignore any additional properties, or MAY return an error if those properties are considered incompatible with the creation request. |
CONFIG-RES-126 | Any properties required on new streams or baselines not defined by this standard MUST be described in resource shapes referenced by oslc:resourceShape properties on the container. |
CONFIG-RES-127 | Servers SHOULD support the Prefer header for GET on those LDPCs specifying PreferMinimalContainer: |
CONFIG-RES-128 | Servers MAY support OSLC selective properties on a GET |
CONFIG-RES-129 | When adding a contribution, if the configuration being added has anoslc_config:overrides relationship, that relationship MUST be copied to the contribution. |
CONFIG-RES-130 | If the configuration being added has no OSLC overrides - it is a reusable configuration - a client MAY include an oslc_config:overrides relationship in a PUT to the contribution resource. |
CONFIG-RES-131 | Servers MAY require an overriding configuration to be for the same component as the overridden contribution. |
CONFIG-RES-132 | Servers MAY report an error if the configuration identified in the oslc_config:overrides property does not exist in the hierarchy for the context configuration. |
CONFIG-RES-133 | if there is no version of that resource in any of the selections in the contributions to the context configuration, nor in any of the selections in their recursive contributions, the request MUST fail with a 404 Resource not found (note that this includes unbound selections from a selection with typeoslc_config:UnboundSelections) |
CONFIG-RES-134 | if there is exactly one version of that resource in the union of the selections in the recursive contributions, the request MUST return that one version |
CONFIG-RES-135 | the behavior is implementation-defined, but SHOULD be well-defined in that the successive requests in the same configurations with the same selections SHOULD resolve to the same version. A server MAY perform an ordered search using the oslc_config:contributionOrder property, and MAY have a way to indicate multiple possible version resolutions |
CONFIG-RES-136 | During this version resolution, overrides for entire configurations MUST be taken into account. If a contribution is marked as an override and the overriding configuration is earlier in the ordered set of all recursive contributions than the overridden configuration, the overridden configuration and all its contributions MUST be ignored in their entirety. Servers MAY report an error if an overriding configuration is later in the ordered set of all recursive contributions than the overridden configuration. |
CONFIG-RES-137 | Overrides from change set configurations MUST also be taken into account. If a change set removes a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, then the request MUST fail with a 404 Resource not found. If a change set replaces a selection for a versioned resource in the overridden configuration, and no other selection is provided for that resource in some other configuration, the request MUST return the version in the change set selection. |
CONFIG-RES-138 | Implementations SHOULD provide documentation on their version resolution behavior. |
CONFIG-RES-139 | All configuration servers MUST provide a delegated user interface dialog for selection of configurations. A global configuration server MUST provide, and a local configuration server MAY provide, a delegated user interface dialog for creation of configurations. |
CONFIG-RES-140 | In order to provide a good user experience when selecting configurations to be used as contributions to a parent configuration, the UI Consumer SHOULD provide the URI of the parent configuration as a parameter to the Delegated UI Dialog, using the parameter oslc_config.parentConfiguration. UI Providers SHOULD use the types and oslc_config:accepts property values of that resource to filter the list of potential contributions shown in the selection dialog. |
CONFIG-RES-141 | Tools providing versioned resources using configuration management systems SHOULD provide delegated user interface dialogs for selection of versioned resources in the context of a configuration, and MAY provide delegated user interface dialogs for creation of versioned resources in the context of a configuration. |
CONFIG-RES-142 | Configuration servers SHOULD implement [OSLCCore3] UI Previews and compact rendering. |
CONFIG-RES-143 | Where implemented, clients MUST pass any required configuration context on the initial request for a compact resource, and the configuration server MUST return a compact resource honoring that configuration context. |
CONFIG-RES-144 | Moreover, the icon reference, the large preview reference, the small preview reference, and any image or intra-page references directly embedded in the large and small HTML preview documents in that compact resource_MUST_ correspond to the given configuration context, so the client need not pass a configuration context to render the icon or the HTML preview. |
CONFIG-RES-145 | A configuration server SHOULD provide one or more Tracked Resource Sets for configurations, contributions, and components. A configuration server MAY publish selections and versioned resources in a Tracked Resource Set (TRS); URIs for versioned resources in the base and change log of the TRS MUST be version resource URIs. |
CONFIG-RES-146 | Configuration servers MAY support [OSLCQuery] for configurations and components. If OSLC Query is provided, queries for the following properties using oslc.where and oslc.select SHOULD be supported: |
CONFIG-RES-147 | Query for other properties MAY be supported. |
CONFIG-RES-148 | Servers that support query capabilities on versioned resources MUST support the use of a configuration context to limit the query results to the versions selected by that configuration context, or to unversioned resources. The configuration context MUST support reference of a global configuration, or a configuration from this server. |
CONFIG-RES-149 | A global stream MUST accept any suitable configuration (baseline or stream) from an arbitrary configuration server |
CONFIG-RES-150 | servers MAY use inference through properties such as owl:sameAs andrdfs:subClassOf to extend the definition of matching configuration types |
CONFIG-RES-151 | Any configuration that is suitable to be a contribution to a global configuration (including global configurations themselves) MUST have an oslc_config:acceptedBy property with the valueoslc_config:Configuration |
CONFIG-RES-152 | A server MAY use this to indicate a stream being used to stage the progressive construction of a baseline |
CONFIG-RES-153 | Configuration servers MAY define their own types of configuration, and use those types inoslc_config:acceptedBy and oslc_config:accepts properties to define the allowed contributions. |
CONFIG-RES-154 | Servers MAY treat the oslc_config:accepts and oslc_config:acceptedBy as server-generated read-only properties, not modifiable by a client. |
CONFIG-RES-155 | Servers MAY perform validation of oslc_config:acceptscode> and oslc_config:acceptedBy. If a server performs such validation, it MAY limit validation to new contributions being added or defined for the first time. |
CONFIG-RES-156 | Servers MAY use the standard HTTP response 202 Request Accepted to indicate that a request has been accepted, but may not yet be complete. |
CONFIG-RES-157 | The content and location header of this 202 response MUST be that of anoslc_config:Activity resource, indicating the progress or result of that activity. Clients SHOULD poll the Activity resource periodically until the state indicates it has finished. |
CONFIG-RES-158 | Each Activity resource MUST be persisted by a server (including over a restart) for a minimum of 24 hours after completion of the long operation as a whole, or until explicitly deleted by a client. |
CONFIG-RES-159 | Clients SHOULD delete each Activity created by a long-running operation soon after the client has seen the completion of the activity, or when the client is no longer interested in the result. Servers MAY deny clients access to delete Activity resources including but not limited to activities still in progress, or activities not created by that client, or MAY require clients to have a specific role or permission to delete activities. |
CONFIG-RES-160 | Each resource SHOULD have one instance of the dcterms:created property |
CONFIG-RES-161 | the dcterms:references property MUST be present, providing a link to the primary resource created or affected by the operation |
CONFIG-RES-162 | For activities still in progress, this MAY be a reference to a resource providing further information; which MAY be provided inline |
CONFIG-RES-163 | Instances of this property MAY appear at any time during the execution of the activity, or MAY be returned only after the activity is complete |
CONFIG-RES-164 | An Activity MUST have a resource type of oslc_config:Activity, and MAY have other types |