OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-ccm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes of today's OASIS OSLC CCM TC meeting

The minutes for this morning's meeting may be found at https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2016.07.14, and are included below.

Chat transcript from room: oslc-ccm 2016-07-14 GMT-08:00
[07:04] Nick Crossley (IBM): Nick to scribe
[07:04] List of attendees: Brian Steele (IBM), David Honey (IBM), Jim Amsden (IBM), Nick Crossley (IBM), Peter Hack (IBM)
[07:04] Nick Crossley (IBM): Minutes of last meeting at https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2016.06.30
[07:05] Nick Crossley (IBM): Minutes of previous meeting approved
[07:05] Nick Crossley (IBM): Change Management topics
[07:05] Nick Crossley (IBM): Jim: issue 26
[07:05] David Honey (IBM): https://issues.oasis-open.org/browse/OSLCCCM-26
[07:05] Jim Amsden (IBM): https://issues.oasis-open.org/browse/OSLCCCM-26
[07:06] Nick Crossley (IBM): Changes made, and reviewed: issue to be closed
[07:06] David Honey (IBM): https://issues.oasis-open.org/browse/OSLCCCM-27
[07:07] Nick Crossley (IBM): Discussion to be deferred until Martin is present
[07:07] David Honey (IBM): https://issues.oasis-open.org/browse/OSLCCCM-29
[07:07] Nick Crossley (IBM): Same with issue 29
[07:08] Nick Crossley (IBM): Configuration Management
[07:11] David Honey (IBM): https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt/config-resources.html
[07:11] David Honey (IBM): Sections 5.1 and 5.2
[07:13] Nick Crossley (IBM): On default configuration:
If a configuration context is not provided or implied, the server MAY provide a default configuration, or the request MAY fail. A provider MAY include an <code>oslc_config:configurationSettings</code> link in the OSLC Service resource, referencing an <code>oslc:ConfigurationsSettings</code> resource. That resource MAY contain an <code>oslc_config:defaultConfiguration</code> property whose value is the URI of the default configuration to be used by that service. An <code>oslc_config:defaultConfiguration</code> property with an rdf:nil value implies there is no default configuration, so requests with no context will fail. Servers MAY support a PUT on <code>oslc:ConfigurationsSettings</code> resource as a way to set the default configuration. Servers MAY provide other ways for users to set the default configuration.</p>
[07:20] Nick Crossley (IBM): Nick to review overall structure of Config Management spec, to see if compliance requirements could/should be each in separate numbered sections.
[07:22] Nick Crossley (IBM): Third sentence should be: "An <code>oslc_config:defaultConfiguration</code> property with an rdf:nil value implies there is no default configuration, so requests with no context MUST fail."
[07:23] Nick Crossley (IBM): Next part of this concerns the identification of which config was used for a request:
[07:24] Nick Crossley (IBM): Identifying the configuration used by a request
Where the response to a GET is a single versioned resource, the server SHOULD include a <code>Configuration-Context</code> header indicating the precise configuration in which that resource was found. Note this is frequently not the same as the context on the request: the context on the request is likely to be a global configuration, while the context on the response, if present, MUST be the leaf-level provider-specific configuration used to resolve the version. This could be either a direct or indirect contribution to the requested context, or it could be the default configuration.
[07:36] Nick Crossley (IBM): There are difficulties in this proposal - the language about 'precise configuration' is not precise, and does not address the case where a resource is split across multiple local configurations.
[07:36] Nick Crossley (IBM): Suggest we drop this part.
[07:36] Nick Crossley (IBM): Will discuss in a future meeting.
[07:38] Nick Crossley (IBM): Last part marked in red: on deletion of baselines.
[07:38] Nick Crossley (IBM): Since providers may support deletion of baselines, clients must not assume that references to baselines can be resolved; like any other resource, clients must be prepared to handle 404 errors. Since baselines are normally linked into a provenance chain using the <code>oslc_config:previousBaseline</code> property, servers may elect to leave a stub resource behind instead of truly deleting a baseline.
[07:47] Nick Crossley (IBM): Discussion about lifetime of baselines: Jim wondered if there should be a property to indicate the 'release' state of a baseline
[07:50] Nick Crossley (IBM): Nick described how the early TC discussions explicitly decided not to include workflow/lifecycle attributes
[07:50] Nick Crossley (IBM): ACTION: Nick will explain the 'stub resource' more.
[07:51] Nick Crossley (IBM): Any other business?
[07:51] Nick Crossley (IBM): Meeting adjourned.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]