[LOGO] Subversion Repositories oslc-ccm

[/] [trunk/] [specs/] [config-mgt.html] - Rev 2

Go to most recent revision | Download | Compare with Previous | Blame | View Log

<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
<title>OSLC Configuration Management</title>
<script src='http://sspeiche.github.io/respec/builds/oasis/respec-oasis-common.js' async class='remove'></script>
<script class='remove'>
  var respecConfig = {
      // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
      specStatus:           "WD",
      edDraftURI:           "config-mgt.html",
      
      // the specification's short name, as in http://www.w3.org/TR/short-name/
      shortName:            "OSLC Configuration Management 1.0",

      // if your specification has a subtitle that goes below the main
      // formal title, define it here
      // subtitle   :  "an excellent document",

      // if you wish the publication date to be other than the last modification, set this
      // publishDate:  "2009-08-06",

      // if the specification's copyright date is a range of years, specify
      // the start date here:
      // copyrightStart: "2005"

      // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
      // and its maturity status
      // previousPublishDate:  "1977-03-15",
      // previousMaturity:  "WD",

      // if there a publicly available Editor's Draft, this is the link
      // edDraftURI:           "http://berjon.com/",

      // if this is a LCWD, uncomment and set the end of its review period
      // lcEnd: "2009-08-05",

      // editors, add as many as you like
      // only "name" is required
      editors:  [
          {
              name:       "Nick Crossley"
          ,   mailto:     "ncrossley@us.ibm.com"
          ,   company:    "IBM"
          ,   companyURL: "http://ibm.com/"
          },
      ],
      
      // name of the WG
      wg:           "OASIS OSLC Change and Configuration Management (OSLC CCM) TC",
      
      // URI of the public WG page
      wgURI:        "https://www.oasis-open.org/apps/org/workgroup/oslc-ccm/",
      
      // name (without the @w3c.org) of the public mailing to which comments are due
      wgPublicList: "oslc-ccm",
      
      // URI of the patent status for this WG, for Rec-track documents
      // !!!! IMPORTANT !!!!
      // This is important for Rec-track documents, do not copy a patent URI from a random
      // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
      // Team Contact.
      wgPatentURI:  "",
      // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
  };
</script>
<link rel="stylesheet" type="text/css" href="table-styles.css">
<link rel="stylesheet" type="text/css" href="definition-styles.css">
</head>
<body>
<section id='abstract'>
  <p>This document defines an RDF vocabulary and a set of REST APIs for configuration management of linked data resources from multiple domains.</p>
  <p>Capabilities include:</p>
  <ul>
    <li>Create and update cross-domain or <em>global</em> configurations</li>
    <li>Add  configurations (global, or local to a tool or domain) as contributions to a global configuration</li>
    <li>Identify the version of a given resource within the context of a configuration (global or local)</li>
    <li>Establish a baseline (snapshot) of a global configuration</li>
  </ul>
  <p>The specification allows but does not mandate creation and updating of configurations local to a tool or domain.</p>
  <p>The specification allows but does not mandate capabilities for creation, deletion, and other management of versions of resources other than configurations themselves.</p>
  <p>While the scope of this workgroup does not include all of ITIL or IT Service Management, a configuration as defined by this workgroup shall be able to contain or reference a set of Configuration Items (CIs) and their specific versions, and hence participate in the Identification, Control, and Monitoring activities of ITIL.</p>
</section>
<section id='sotd'>Editor's working draft.</section>
<section id="notation">
  <h2>Notation and Conventions</h2>
  <p>The key words &#8220;MUST&#8221;, &#8220;MUST NOT&#8221;, &#8220;REQUIRED&#8221;, &#8220;SHALL&#8221;, &#8220;SHALL NOT&#8221;, &#8220;SHOULD&#8221;, &#8220;SHOULD NOT&#8221;, &#8220;RECOMMENDED&#8221;, &#8220;MAY&#8221;, and &#8220;OPTIONAL&#8221; in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC&#8211;2119</a>. This document is a mixture of normative and informative text.</p>
</section>
<section id='terminology' class='informative'>
  <h2>Terminology</h2>
  <dl>
    <dt><strong>Version</strong></dt>
    <dd>A referenceable state of a resource. Each version can be referenced with a distinct URI.</dd>
    <dt><strong>Revision</strong></dt>
    <dd>A version of a resource that is designed to replace an earlier version, such as an edited version of a source file, or a modified requirement.</dd>
    <dt><strong>Variant</strong></dt>
    <dd>A version of a resource that is identified by a specific set of characteristics that distinguish it from other versions of that resource, where each variant can exist at the same time as those other versions of the resource.</dd>
    <dt><strong>Component</strong></dt>
    <dd>A unit of organization consisting of a reusable set of engineering resources. Some components correspond to units of configurability (see below).</dd>
    <dt><strong>Configuration</strong></dt>
    <dd>A set of versions of some resources. Configurations commonly identify one version of each resource in a component. The resources can be unchanging (from a baseline) or open to change (in development). In some systems, configurations can be hierarchical, so that they contain other configurations.</dd>
    <dt><strong>Global Configuration</strong></dt>
    <dd>A configuration that identifies a set of configurations contributed by multiple tools or configuration management providers, allowing you to define all the relevant resources for a system. Using global configurations, you can establish a configuration context across multiple tools, even when each tool stores its resources in otherwise unrelated configurations and respositories.</dd>
    <dt><strong>Contribution</strong></dt>
    <dd>A configuration that is a member of the set of configurations making up a global configuration. When a configuration is contributed to a global configuration, the set of versions of resource in that configuration are logically added to the set of versions in that global configuration.</dd>
    <dt><strong>Branch</strong></dt>
    <dd>(verb) to create a configuration for parallel or insulated development.<br>
      (noun) the result of parallel or insulated development after branching - that is, a sequence of baselines, usually with a stream at the end of the branch.</dd>
    <dt><strong>Baseline</strong></dt>
    <dd>An immutable configuration of one or more components that corresponds to some meaningful state of its resources. Baselines are useful for recording deliverables, enabling a team to work with a known configuration, or as an initial state for some new stream of work.</dd>
    <dt><strong>[Work] stream</strong></dt>
    <dd>A modifiable configuration of resources. For example, team members deliver to a stream when they want to make their changes visible to other team members.</dd>
  </dl>
</section>
<section id='namespaces'>
  <h2>Namespaces</h2>
  <p>In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the OSLC Core specification, OSLC Configuration Management defines the namespace URI of <code>http://open-services.net/ns/config#</code> with a namespace prefix of oslc_config.</p>
  <p>This specification also uses these namespace prefix definitions:</p>
  <table>
    <tr>
      <td><code>prov:</code></td>
      <td><code>http://www.w3.org/ns/prov#</code></td>
      <td>(W3C provenance vocabulary)</td>
    </tr>
  </table>
</section>
<section id='resources' class='informative'>
  <h2>Concept and Version Resources</h2>
  <p>All the major &ldquo;Artifacts&rdquo; or &ldquo;Entities&rdquo; in OSLC domains are <strong><em>Concept Resources</em></strong>. Examples are defects, tasks, products, projects, users, tests cases requirements, plans and so on. Like all resources, concept resources have URLs. Except in a few technical and specialized scenarios, URLs of concept resources are used throughout the system. &ldquo;Entities&rdquo; are addressed in HTTP messages via their concept resource URLs. Links are typically established using the URL of a concept resource.</p>
  <p>A version resource defines a particular version of the state of a concept resource. A version resource MUST have a type of <code>oslc_config:VersionedResource</code>.</p>
  <p>A GET on the URI of a concept resource resolves that URI to an appropriate state of (version of) that concept resource for the appropriate configuration context (see later). The returned resource may contain RDF statements about both the version resource and the concept resource; most statements should use the concept resource as the subject, because a version resource reflects the state of (properties of) the concept resource as it appeared at some time. Using the concept resource URI as the subject of RDF statements is more consistent with the handling of non-versioned resources; using the versioned resource URI as the subject of RDF statements requires more client knowledge of versioning.</p>
  <p>Since different versions reflecting different states of the concept resource may return conflicting RDF statements about the same subject, it is important for clients handling multiple versions (multiple configurations) to keep track of the relevant versions; this may be done using RDF named graphs.</p>
  <p>The <code>dcterms:isVersionOf</code> property relates the version resource itself to its concept resource; this property is mandatory for all versioned resources.</p>
  <p>As an example, <code>GET http://example.com/conceptResourceA</code> in one configuration context might return:</p>
  <pre>:conceptResourceA-version23
        a oslc_config:VersionedResource ;
        dcterms:isVersionOf :conceptResourceA .
:conceptResourceA
        a :someType ;
        dcterms:title &quot;Concept Resource A&quot; ;
        :color &quot;blue&quot; ;
        dcterms:description &quot;Concept resource A as it appears in the state with the URI :conceptResourceA-version23&quot; .</pre>
  <p>while in a different configuration context it might return:</p>
  <pre>:conceptResourceA-version17
        a oslc_config:VersionedResource ;
    dcterms:isVersionOf :conceptResourceA .
:conceptResourceA
    a :someType ;
    dcterms:title &quot;Concept Resource A&quot; ;
    :color &quot;red&quot; ;
    dcterms:description &quot;Concept resource A as it appears in the state with the URI :conceptResourceA-version17&quot; .</pre>
  <p>To keep track of which version represented which state of the conflicting color statements, use of RDF named graphs is recommended, as shown here using <a href="http://www.w3.org/2010/01/Turtle/Trig">TriG</a>:</p>
  <pre>:conceptResourceA-version23 = {
        :conceptResourceA-version23
                a oslc_config:VersionedResource ;
                dcterms:isVersionOf :conceptResourceA .
        :conceptResourceA
                a :someType ;
                dcterms:title &quot;Concept Resource A&quot; ;
                :color &quot;blue&quot; ;
                dcterms:description &quot;Concept resource A as it appears in the state with the URI :conceptResourceA-version23&quot; .
}.
   
:conceptResourceA-version17 = {
        :conceptResourceA-version17
                a oslc_config:VersionedResource ;
                dcterms:isVersionOf :conceptResourceA .
        :conceptResourceA
                a :someType ;
                dcterms:title &quot;Concept Resource A&quot; ;
                :color &quot;red&quot; ;
                dcterms:description &quot;Concept resource A as it appears in the state with the URI :conceptResourceA-version17&quot; .
}.</pre>
  <p>A GET on the URI of a concept resource with no configuration context MAY be resolved using a provider-specific default context, or MAY fail.</p>
</section>
<section id='vocabulary'>
  <h2>Vocabulary</h2>
  <p>Classes - Configuration, Component, VersionedResource</p>
  <p>Properties - immutable, versionId, component</p>
  <h2>Shapes</h2>
  <table>
    <tr>
      <th colspan="6">OSLC Core properties used by all Configuration Management resources</th>
    </tr>
    <tr>
      <th>Prefixed Name</th>
      <th>Occurs</th>
      <th>Read-only</th>
      <th>Value-type</th>
      <th>Representation</th>
      <th>Description</th>
    </tr>
    <tr>
      <td colspan="6"><strong>OSLC Core</strong>: Common Properties</td>
    </tr>
    <tr>
      <td><code>rdf:type</code></td>
      <td>one-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The resource type URIs.</td>
    </tr>
    <tr>
      <td><code>dcterms:contributor</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Either</td>
      <td>Contributor or contributors to resource (reference: Dublin Core). It is likely that the target resource is a [ <code>foaf:Person</code> ](http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#foaf_Person_Resource) but that is not necessarily the case.</td>
    </tr>
    <tr>
      <td><code>dcterms:created</code></td>
      <td>zero-or-one </td>
      <td>True</td>
      <td>DateTime</td>
      <td>n/a</td>
      <td>Timestamp of resource creation (reference: Dublin Core)</td>
    </tr>
    <tr>
      <td><code>dcterms:creator</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Either</td>
      <td>Creator or creators of resource (reference: Dublin Core). It is likely that the target resource is a [ <code>foaf:Person</code> ](http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#foaf_Person_Resource) but that is not necessarily the case.</td>
    </tr>
    <tr>
      <td><code>dcterms:description</code></td>
      <td>zero-or-one</td>
      <td>unspecified</td>
      <td>XMLLiteral</td>
      <td>n/a</td>
      <td>Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <code>&lt;div&gt;</code> element.</td>
    </tr>
    <tr>
      <td><code>dcterms:identifier</code></td>
      <td>exactly-one</td>
      <td>True</td>
      <td>String</td>
      <td>n/a</td>
      <td>A unique identifier for a resource. For versioned resources, this identifier is unique across all versions of all resources, not just unique across the concept resources. This property is assigned by the service provider when a resource is created, and is not necessarily intended for end-user display.</td>
    </tr>
    <tr>
      <td><code>dcterms:modified</code></td>
      <td>zero-or-one </td>
      <td>True</td>
      <td>DateTime</td>
      <td>n/a</td>
      <td>Timestamp of latest resource modification (reference: Dublin Core).  Each resource SHOULD have one instance of this property.</td>
    </tr>
    <tr>
      <td><code>dcterms:subject</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>String </td>
      <td>n/a</td>
      <td>Tag or keyword for a resource. Each occurrence of a <code>dcterms:subject</code> property denotes an additional tag for the resource.</td>
    </tr>
    <tr>
      <td><code>dcterms:title</code></td>
      <td>exactly-one</td>
      <td>unspecified</td>
      <td>XMLLiteral</td>
      <td>n/a</td>
      <td>Title (reference: Dublin Core) of the resource represented as rich text in XHTML content.</td>
    </tr>
    <tr>
      <td><code>oslc:serviceProvider</code></td>
      <td>zero-or-many</td>
      <td>True</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>A link to the resource's OSLC Service Provider. There may be cases when the subject resource is available from a service provider that implements multiple domain specifications, which could result in multiple values for this property.</td>
    </tr>
    <tr>
      <td><code>oslc:instanceShape</code></td>
      <td>zero-or-one</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>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 and thus should not be cached.</td>
    </tr>
    <tr>
      <td><code>oslc:shortTitle</code></td>
      <td>zero-or-one</td>
      <td>unspecified </td>
      <td>XMLLiteral</td>
      <td>n/a</td>
      <td>Optional: a shorter form of <code>dcterms:title</code> for the resource represented as rich text in XHTML content. SHOULD include only content that is valid inside an XHTML <code>&lt;span&gt;</code> element.</td>
    </tr>
    <tr>
      <td><code>oslc:shortId</code></td>
      <td>zero-or-one</td>
      <td>unspecified</td>
      <td>String</td>
      <td>n/a</td>
      <td>Optional: a shorter and human-readable form of <code>dcterms:identifier</code> for the resource, such as a number.</td>
    </tr>
    <tr>
      <td><code>oslc:modifiedBy</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Either</td>
      <td>The URI of a resource describing the entity that most recently modified the subject resource. The link target is usually a <code>foaf:Person</code> or <code>foaf:Agent</code>, but could be any type. This is modeled after <code>dcterms:creator</code>, but Dublin Core currently has no equivalent property.</td>
    </tr>
    <tr>
      <td colspan="6"><strong>W3C Provenance Properties</strong></td>
    </tr>
    <tr>
      <td><code>prov:wasDerivedFrom</code>, <code>prov:wasRevisionOf</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Either</td>
      <td>Previous versions or revisions of this resource.</td>
    </tr>
    <tr>
      <td><code>prov:wasGeneratedBy</code></td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Either</td>
      <td>A change set or similar activity that generated this resource. It is likely that the target resource is an <code>oslc_config:ChangeSet</code> or an <code>oslc_cm:ChangeRequest</code> but that is not necessarily the case.</td>
    </tr>
  </table>
  <h3>Configuration Item</h3>
  <p>Resources of any type may appear as configuration items - resource that appear as members of configurations or change sets. Configuration items MAY have any of the common properties shown above, and MAY have any other properties. Configuration items that represent versions of a concept resource MUST have an <code>rdf:type</code> triple whose subject is the version resource URI and who object is <code>oslc_config:VersionedResource</code>, and a single <code>dcterms:isVersionOf</code> triple whose subject is the version resource and whose object is the concept resource.  Configuration items that are versioned resources have the following  additional properties, using the concept resource URI as the subject:OLOR="#A020F0"></p>
  <table>
    <tr>
      <th colspan="6">Properties of a Configuration Item</th>
    </tr>
    <tr>
      <th>Prefixed Name</th>
      <th>Occurs</th>
      <th>Read-only</th>
      <th>Value-type</th>
      <th>Representation</th>
      <th>Description</th>
    </tr>
    <tr>
      <td><code>oslc_config:versionId</code></td>
      <td>zero-or-one</td>
      <td>unspecified</td>
      <td>String</td>
      <td>n/a</td>
      <td>A short human-readable identifier for the version of a resource.  All versioned resources SHOULD have this property; where the property is present, this identifier MUST be unique amongst all currently existing versions of the same concept resource. </td>
    </tr>
  </table>
  <h3>Configuration</h3>
  <p>A configuration is a Linked Data Platform Container resource with the common properties, plus the following:</p>
  <table>
    <tr>
      <th colspan="6">Properties of a Configuration </th>
    </tr>
    <tr>
      <th>Prefixed Name</th>
      <th>Occurs</th>
      <th>Read-only</th>
      <th>Value-type</th>
      <th>Representation</th>
      <th>Description</th>
    </tr>
    <tr>
      <td><code>rdf:type</code></td>
      <td>one-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The resource type URIs.  A configuration MUST have a resource type of <code>oslc_config:Configuration</code>.  A configuration that has contributions or sub-configurations (contains or aggregates other configurations) MUST also have a resource type of <code>ldp:Container</code>.  The members of this container are the aggregated configurations.</td>
    </tr>
    <tr>
      <td>TBD - LDPC membership predicate(s)</td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The member configurations of this configuration.</td>
    </tr>
    <tr>
      <td><code>oslc_config:component</code></td>
      <td>exactly-one</td>
      <td>false</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The component of which this is a configuration. The component identifies the set of resources (configuration items) in the configuration.</td>
    </tr>
    <tr>
      <td><code>oslc_config:componentVersion</code></td>
      <td>exactly-one</td>
      <td>false</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The version used by this configuration of the oslc_config:component. This version of the component identifies the versions of the resources (configuration items) in the configuration.</td>
    </tr>
    <tr>
      <td><code>oslc_config:mutable</code></td>
      <td>exactly-one</td>
      <td>true</td>
      <td>Boolean</td>
      <td>n/a</td>
      <td>Whether the set of versioned artifact states selected by this configuration can be changed.  Note that this property may not be modified directly, but there are explicit operations to create mutable configurations (streams) from immutable baselines, and vice versa. Other than this flag, configurations do not have status, workflow, or lifecycle properties; instead, we expect other resources that define such status to link to configurations.  These other resources might be Change Requests, or resources from some as-yet undefined OSLC Lifecycle or Process Domain. The title and tags of a configuration may be modified regardless of the setting of this <code>mutable</code> properry.</td>
    </tr>
    <tr>
      <td><code>oslc_config:action</code></td>
      <td>zero-or-many</td>
      <td>true</td>
      <td>Resource</td>
      <td>Either</td>
      <td>The referenced resources MUST be of type oslc_config:Action. This property indicates one of the available action that may be performed on this configuration.  See TBD. </td>
    </tr>
  </table>
  <h3>Component<br>
  </h3>
  <p>A component is a Linked Data Platform Container identifying a set of resources that are configured together as a unit.  The granularity of a component varies between providers, but typically it contains the set of resources of some type being used in some project, or a subdivision of such a set. A component has the common properties, plus the following:</p>
  <table>
    <tr>
      <th colspan="6">Properties of a Component</th>
    </tr>
    <tr>
      <th>Prefixed Name</th>
      <th>Occurs</th>
      <th>Read-only</th>
      <th>Value-type</th>
      <th>Representation</th>
      <th>Description</th>
    </tr>
    <tr>
      <td><code>rdf:type</code></td>
      <td>one-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The resource type URIs.  A component MUST have a resource type of <code>oslc_config:Component</code>. A component that has any contained configuration items MUST also have a resource type of <code>ldp:Container</code>, and MAY have other types. The members of this container are the version resources (configuration items) in this component; the container may be empty for a compoent that has no configuration items, or one that does not publish its members. Note that a GET an a component in the context of a configuration MUST return the version resource URIs of the members.</td>
    </tr>
    <tr>
      <td>TBD - LDPC membership predicate(s)</td>
      <td>zero-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The member resources (configuration items) in this component. When fetching this property in the context of a configuration of this component, versioned resource members MUST be identified by a URI specific to the version of the resource in that context.</td>
    </tr>
  </table>
  <p>A component itself MAY be a versioned resource, indicated by the RDF type oslc_config:VersionedResource.</p>
  <p>Typically, components themselves are not nested - that is, typically none of the members of an <code>oslc_config:Component</code> container are themselves of type <code>oslc_config:Component</code>; any required structure and hierarchy is realized through configurations, or through the structures within the configuration items themselves (e.g., versioned folders or directories). TBD: can we make this a MUST to simplify client processing? Similarly, can we exclude subconfigurations from appearing in this flattened list of configuration items?</p>
  <h3>VersionedResource</h3>
  <p>This type is used as a marker for any versioned resource. There are two mandatory properties for a versioned resource:</p>
  <table>
    <tr>
      <th colspan="6">Properties of a VersionedResource</th>
    </tr>
    <tr>
      <th>Prefixed Name</th>
      <th>Occurs</th>
      <th>Read-only</th>
      <th>Value-type</th>
      <th>Representation</th>
      <th>Description</th>
    </tr>
    <tr>
      <td><code>rdf:type</code></td>
      <td>one-or-many</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The resource type URIs.  A versioned resource MUST have a resource type of <code>oslc_config:VersionedResource</code>, and SHOULD have other types.</td>
    </tr>
    <tr>
      <td>dcterms:isVersionOf</td>
      <td>exactly-one</td>
      <td>unspecified</td>
      <td>Resource</td>
      <td>Reference</td>
      <td>The concept resource of which this resource is a version.</td>
    </tr>
  </table>
  <p>&nbsp;</p>
</section>
<section id='context'>
  <h2>Configuration context</h2>
  <p>The initial configuration context is to be established by the user and the system in an appropriate manner - possibly stored in a preference, picked up from an initial resource, selected from a dialog, etc.</p>
  <p>While navigating between resources, resources of certain types MAY indicate that a different context is to be used when followings links from that resource. For example, if a member of the current configuration context is itself a configuration, that sub-configuration MUST be used as the context for resources contained in that sub-configuration. .</p>
  <p>A client may request a specific configuration context in one of two ways.</p>
  <p>When performing a GET on a concept URI, add an <code>X-OSLC-Configuration-Context </code>header, passing the URI of a configuration resource as the value:</p>
  <pre>GET /resources/conceptResourceA HTTP/1.1
X-OSLC-Configuration-Context: http://example.com/configurations/myConfiguration1</pre>
  <p>When performing a GET on a concept URI, add a query string <code>oslc_config.context</code> and the encoded configuration URI to the end of the request URI:</p>
  <pre>GET /resources/conceptResourceA?oslc_config.context=&amp;3Chttp&amp;3A//example.com/configurations/myConfiguration1&amp;3E HTTP/1.1</pre>
</section>
<section id='factories'>
  <h2>Creation Factories</h2>
  <p>A global configuration provider MUST provide a creation factory for new global configurations. A local configuration provider MAY provide creation factories for local configurations and configuration items. This specification does not determine the semantics of or required properties for configuration item factories.</p>
</section>
<section id='delegateduis'>
  <h2>Delegated UIs</h2>
  <p>A global configuration provider MUST provide delegated user interface dialogs for creation and selection of configurations. A local configuration provider MUST provide a delegated user interface dialog for selection of configurations, and MAY also provide a delegated dialog for creation   of configurations.</p>
  <p>Tools providing versioned resources using configuration management systems SHOULD provide delegated user interface dialogs for   selection of configuration items, and MAY provide delegated user interface dialogs for creation of configuration items.</p>
</section>
<section id='trs'>
  <h2>Tracked Resource Sets</h2>
  <p>A configuration provider SHOULD, and a global configuration provider MUST, provide a Tracked Resource Set for configurations and components. A configuration provider MAY publish configuration items in the same or a different Tracked Resource Set. Configuration providers that choose not to publish configuration items in a Tracked Resource Set MUST provide empty containers for the component resources.</p>
</section>
<section id='discovery'>
  <h2>Service Discovery and Registration</h2>
  <p>TBD - how a local configuration provider finds its global configuration provider.</p>
  <p>TBD - how a global configuration provider finds the possible local configuration providers that might contribute to global configurations.</p>
  <p>TBD - are multiple global configuration providers supported, and how they discover each other?</p>
  <p>TBD - is any kind of subscription and/or update notification required?</p>
</section>
<section id='itemoperations'>
  <h2>Supported Operations on Configuration Items</h2>
  <p>A configuration provider 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 provider:</p>
  <ul>
    <li>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.</li>
    <li>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 is bound MUST fail with an HTTP 404 error.</li>
    <li>PUT: Update the state of a specified versioned concept resource in a specified stream; this operation might or might not cause the creation of a new version of the resource.</li>
  </ul>
  <p>A configuration provider MAY support the following operations on configuration items in the context of a global configuration, or in the context of a configuration from this provider:</p>
  <ul>
    <li>POST to a component container in the context of a stream, resulting in the creation of the first version of a new concept resource, or a new version of an existing resource</li>
    <li>DELETE: Delete the current mutable version resource in a specified stream.</li>
  </ul>
</section>
<section id='configoperations'>
  <h2>Supported Operations on Configurations</h2>
  <p>A configuration provider MUST support the following operations on configurations:</p>
  <ul>
    <li>HEAD and OPTIONS: Retrieve information about the configuration, including link headers compliant with the W3C Linked Data Platform specification indicating the non-member resource.</li>
    <li>GET: Retrieve the current state of the configuration.</li>
  </ul>
  <p>A configuration provider MAY support, and a global configuration provider MUST support, the following operations on configurations:</p>
  <ul>
    <li>POST on the configuration container to create a new stream sub-configuration</li>
    <li>PUT and/or PATCH on the configuration container to update the tags and/or the set of sub-configurations</li>
    <li>DELETE a configuration; providers MAY refuse to delete configurations that are part of or referenced by existing baselines.</li>
  </ul>
</section>
<section id='actions'>
  <h2>Automation and Actions</h2>
  <p>OSLC Configuration Management providers MUST implement the Core Actions specification, and SHOULD implement the Automation specification.</p>
  <p>A global configuration provider MUST provide actions that:</p>
  <ul>
    <li>Operating on a global configuration, find the contribution (searching recursively) that has the given component</li>
    <li>Operating on a global baseline or global stream, create a copy of that global configuration, wherein each global baseline contribution (recursively top down) is replaced by a global stream with the same initial state as the global baseline.</li>
    <li>Operating on a global stream, commit a baseline (with optional tags), wherein each global stream contribution (recursively bottom up) is converted into a global baseline if and only if all its contributions are baselines.</li>
  </ul>
  <p>All configuration providers MUST provide an action that:</p>
  <ul>
    <li>Query for the most recently created baseline of a given component, optionally restricting the result to baselines with a given tag or tags</li>
  </ul>
  <p>A configuration provider MAY support actions that:</p>
  <ul>
    <li>Operating on a stream, create a new baseline (with optional tags) that captures the current state of (and configuration item versions in) that stream. This operation MAY operate recursively on sub-configurations, or MAY fail or not complete if any sub-configuration is not already a baseline.</li>
    <li>Operating on a baseline or stream, create a copy of that configuration (with optional tags), wherein each baseline sub-configuration (recursively top down) is replaced by a stream with the same initial state as the baseline.</li>
  </ul>
</section>
<section id='skew' class='informative'>
  <h2>Version and Component Skew</h2>
  <p>Version skew occurs when two or more different versions of a single configuration item (same concept resource) are present in a single configuration. Not many configuration management systems support version skew. This specification does not address version skew other than through component skew.</p>
  <p>Component skew occurs when two or more configurations (typically baselines) of the same component are used in or below a parent configuration. Global configuration providers MUST support component skew, and other configuration management providers MAY support it.</p>
  <p>Handling of and resolution of skew TBD. </p>
</section>
<section id='issues' class='informative'>
  <h2>Issues and other TBDs</h2>
  <ul>
    <li>Exact details on location headers and other link headers returned from each operation and action (X-... headers must be replaced by properly registered ones)</li>
    <li>Handling of non-RDF versioned resources</li>
    <li>Updates for latest W3C LDP specification, including container types and required predicates</li>
    <li>Required support for OSLC simple query</li>
    <li>Error conditions and status codes</li>
    <li>Examples and sequence diagrams - put in primer, not in spec</li>
  </ul>
</section>
</body>
</html>

Generated by GNU enscript 1.6.4.

Go to most recent revision | Compare with Previous | Blame