[OASIS Issue Tracker] (OSLCCCM-35) Resource shape for creating streams

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/OSLCCCM-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Crossley updated OSLCCCM-35:
---------------------------------

    Proposal: 
Add oslc:creationShape to both the streams LDPC on a baseline, and the baselines LDPC on a stream.
Add spec text:
Providers SHOULD support the Prefer header for GET on those LDPCs specifying Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer";, allowing a client to retrieve properties about the LDPC, including its creationShape, without needing to retrieve all membership triples.
Providers MAY support selective properties on a GET, allowing a client to specify exactly which properties of those LDPCs are to be returned.

  was:Either (3) or (4) seem appropriate. (4) is more in keeping with OSLC discovery mechanisms, but (3) is better suited for LDPCs.


> Resource shape for creating streams
> -----------------------------------
>
>                 Key: OSLCCCM-35
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-35
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Improvement
>          Components: Configuration Management
>            Reporter: David Honey
>
> The two recommended approach in the OSLC Configuration Management spec to create a new stream of a component are:
> a) perform a GET on an existing baseline of the component to get  its streams LDPC.
> b) perform a GET on the component to get its configurations LDPC.
> A client can then POST content to the LDPC from (a) or (b).
> However, if the client wants to know what properties it can include in the POSTed RDF, how can it discover the resource shape?
> A similar issue relates to a GET on an LDPC. If it supports oslc.where, how does an OSLC client discover the query resource shape for that LDPC?
> For (a), a client might use the resource instance shape of the baseline. However, that resource shape might show that some properties are read-only because they are immutable on baselines. So is this the right way?
> For (b), there is no documented method.
> There are a number of approaches we might consider:
> 1) Declare a creation factory for every component, and each factory can declare a resource shape. A significant problem with this approach is that there could be a very large number of components, and the OSLC SPC could become very large.
> 2) Have the RDF returned by a GET on the streams LDPC include a reference to the resource shape for new streams of that component. A significant problem with this approach is that a GET on the LDPC would, by default, return all the streams of that component and all their properties. So this seems like a heavyweight means to get the resource shape.
> 3) Include an additional statement in a component's RDF to the resource shape for configurations of that component, and include an additional statement in a baseline's RDF to the resource shape of streams created from it. For example, include an oslc_config:configurationResourceShape statement in a component's RDF to a resource shape for creating new streams or configurations of that component, and include an oslc_config:streamResourceShape to a resource shape for creating a new stream from that baseline. This is lightweight and keeps the discovery of the streams LDPC and its resource shape in the same place.
> 4) Drop support for POST on a component's configurations LDPC and a baseline's streams LDPC, and instead declare a configuration creation factory for each project area specific service provider. A client would need to include oslc_config:component to specify the component for the new stream.
> There is a related issue about how to discover the resource shape when creating a baseline from a stream. However, there is potentially already a method for doing so - the user could use the resource instance shape of the stream.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)