OSLC Configuration Management Version 1.0 (2022-05-30)

OSLC Configuration Management Version 1.0. Part 3: Configuration Specification Project Specification 01 30 May 2022 This stage: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.html (Authoritative) https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.pdf Previous stage: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/psd01/config-resources.html (Authoritative) https://docs.oasis-open-projects.org/oslc-op/config/v1.0/psd01/config-resources.pdf Latest stage: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/config-resources.html (Authoritative) https://docs.oasis-open-projects.org/oslc-op/config/v1.0/config-resources.pdf Latest version: https://open-services.net/spec/config/latest Latest editor's draft: https://open-services.net/spec/config/latest-draft Open Project: OASIS Open Services for Lifecycle Integration (OSLC) Open Project Project Chairs: Jim Amsden ( [email protected] ), IBM Andrii Berezovskyi ( [email protected] ), KTH Editor: Nick Crossley ( [email protected] ), IBM Additional components: This specification is one component of a Work Product that also includes: OSLC Configuration Management Version 1.0. Part 1: Overview . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/oslc-config-mgt.html OSLC Configuration Management Version 1.0. Part 2: Versioned Resources . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/versioned-resources.html OSLC Configuration Management Version 1.0. Part 3: Configuration Specification (this document) . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.html OSLC Configuration Management Version 1.0. Part 4: RDF Vocabulary . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-vocab.html OSLC Configuration Management Version 1.0. Part 5: Machine Readable Vocabulary Terms . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-vocab.ttl OSLC Configuration Management Version 1.0. Part 6: Machine Readable Vocabulary Constraints . https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-shapes.ttl RDF Namespaces: http://open-services.net/ns/config# Abstract: This part of the OSLC Configuration Management Specification defines the representation and behavior of components and configurations of resources in those components (typically referred to as configurations of components, or just configurations). Status: This document was last revised or approved by the OASIS Open Services for Lifecycle Integration (OSLC) Open Project on the above date. The level of approval is also listed above. Check the “Latest stage” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Open Project are listed at https://open-services.net/about/ . Comments on this work can be provided by opening issues in the project repository or by sending email to the project’s public comment list [email protected] . Note that any machine-readable content ( Computer Language Definitions ) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails. Citation format: When referencing this specification the following citation format should be used: [OSLC-Config-1.0-Part3] OSLC Configuration Management Version 1.0. Part 3: Configuration Specification . Edited by Nick Crossley. 30 May 2022. OASIS Project Specification 01. https://docs.oasis-open-projects.org/oslc-op/config/v1.0/ps01/config-resources.html . Latest stage: https://docs.oasis-open-projects.org/oslc-op/config/v1.0/config-resources.html . Notices Copyright © OASIS Open 2013-2022. 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 the OASIS 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 see https://www.oasis-open.org/policies-guidelines/trademark/ for above guidance. Table of Contents 1. Introduction 1.1 Typographical Conventions and Use of RFC Terms 1.2 References 1.2.1 Normative references 2. Service Discovery 3. Component and Configuration Constraints 3.1 Resource shape for Component 3.2 Resource shape for Baseline 3.3 Resource shape for Stream 3.4 Resource shape for ChangeSet 3.5 Resource shape for Contribution 3.6 Resource shape for Selections 3.7 Resource shape for ChangeSet Selections 4. Configuration context 4.1 Default configuration 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 9.1 Creation of Streams 9.2 Creation of Baselines 9.3 Concerns common to streams and baselines 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 in BCP 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 an oslc: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 an oslc_config:Component container are themselves of type oslc_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 Container that 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 a oslc: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 the oslc_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 Container that 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 Container that 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 a oslc: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 the oslc_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 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-81] Syntax of the query string for configuration context: ?oslc_config.context= uri_ref_esc 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] 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-84] 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-85] 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 one oslc_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] POST to the component LDPC to create a new component. A successful response MUST contain a Location header providing the URI of the newly created component. [CONFIG-RES-95] 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 a Location header providing the URI of the newly created component. [CONFIG-RES-96] Servers SHOULD support the Prefer header for GET on LDPCs specifying PreferMinimalContainer: [CONFIG-RES-97] Example 3 Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer" allowing a client to retrieve properties about the LDPC, including any oslc: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 the oslc_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] 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 a Location header specifying the URI of the newly created resource. [CONFIG-RES-113] 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 the oslc_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 a Location 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 the previousBaseline to the new baseline, the server MUST replace all those previousBaseline 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] Servers SHOULD support the Prefer header for GET on those LDPCs specifying PreferMinimalContainer: [CONFIG-RES-127] Example 4 Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer" allowing a client to retrieve properties about the LDPC, including any oslc: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 The oslc_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. A oslc_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 of oslc_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 combined oslc_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 an oslc_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= uri_ref_esc 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 the oslc_config:acceptedBy property on the child configuration and the oslc_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 is oslc_config:Configuration and the child type is either oslc_config:Baseline or oslc_config:Stream . No other form of inference is required, but servers MAY use inference through properties such as owl:sameAs and rdfs: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 value oslc_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 value oslc_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 in oslc_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 an oslc_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 an oslc: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 a oslc: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 a oslc: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 one oslc_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 a Location 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 a Location 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 a Location 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 the oslc_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 a Location 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 the previousBaseline to the new baseline, the server MUST replace all those previousBaseline 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 an oslc_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 type oslc_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 and rdfs: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 value oslc_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 in oslc_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: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-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 an oslc_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

Related documents

• XACML v3.0 Separation of Duties Version 1.0 (2024-01-30)#601007
• XACML v3.0 Time Extensions Version 1.0 (2020-02-14)#601008
• XACML v3.0 XML Digital Signature Profile Version 1.0 (2014-05-19)#601009
• XLIFF v2.0 (2014-08-06)#601010
• XLIFF v2.1 (2018-02-14)#601011