Minutes of today's OASIS OSLC CCM TC meeting

["Nicholas Crossley" <nick_crossley@us.ibm.com>]

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.