Event details


  1. Roll Call
  2. Scribe nomination
  3. Review minutes of previous meeting
  4. Change Management topics
  5. Configuration Management topics
  6. Any other business


Present: Martin Sarabura, Jim Amsden, David Honey, Nick Crossley, Damir Nesic.

Edited chat transcript from room: oslc-ccm 2016-04-21 GMT-08:00

[07:12] Nick Crossley (IBM): Damir introduces himself - interested in vehicle safety, variability, etc.

[07:13] Jim Amsden (IBM): Jim Scribe

[07:13] Nick Crossley (IBM): Review previous minutes at

[07:14] Jim Amsden (IBM): previous meeting minutes approved

Change Management

[07:15] Jim Amsden (IBM): ReSpec changes for CM completed, spec may be ready for CSD vote unless there are additional reviews

[07:17] Jim Amsden (IBM): we have 6 voting members, and 4 are present today.

[07:19] Jim Amsden (IBM): TC should review the CM spec so that we can determine if it is ready for public review

[07:19] Jim Amsden (IBM): Action: Nick will call for CM review pending CSD vote tentatively scheduled for the next meeting.

Configuration Management

[07:20] Jim Amsden (IBM): Nick: Updates to the spec in a few areas

[07:21] Jim Amsden (IBM): Nick: OASIS formatting changes, moving references, reordering sections, no significant content change

[07:21] Jim Amsden (IBM): Nick: haven't yet done the file naming. Have added the multi-part specification

[07:23] Jim Amsden (IBM): Nick: Merged in the changeset branch and now back operating on trunk

[07:24] Jim Amsden (IBM): Nick: Allow override link to be present on configuration or contribution, having it only on the configuration might limit reuse

[07:24] Jim Amsden (IBM): Nick: allows override link to be on contribution and therefore follows its use in different configurations for better reuse of that particular contribution

[07:25] Jim Amsden (IBM): Nick: Can always see data at the contribution level, provides flexibility for users in specifying the configuration

[07:26] Jim Amsden (IBM): CM spec editor draft is not correct

[07:26] Martin Sarabura (PTC):

[07:28] Jim Amsden (IBM): feedback on the list suggesting a change to how to handle the default configuration

[07:30] Jim Amsden (IBM): Airbus (Markus) requires predictability from standards, default is currently MAY, if the client doesn't provide a Configuration-Context. Airbus would like this to be MUST, and provide a URI for client to access to discover the default

[07:31] Jim Amsden (IBM): and POST to that URI would set the default configuration.

[07:32] Jim Amsden (IBM): setting the default by one person changes it for all, this is at odds with the desire for predictable configurations

[07:32] Jim Amsden (IBM): another option is to return an error if the Configuration-Context isn't specified.

[07:33] Jim Amsden (IBM): A global default could be for all users, or a default for each user's session.

[07:34] Jim Amsden (IBM): goal is to make the default more predictable - discover it, and possibly set it.

[07:41] Jim Amsden (IBM): we could change the spec to fail requests that don't provide a Configuration-Context, but this would break all existing integrations

[07:41] Jim Amsden (IBM): Nick: we can't afford to change that, there are too many config-unaware tools that need to interoperate

[07:42] Jim Amsden (IBM): +1

[07:43] Jim Amsden (IBM): use Configuration-Context in the response header giving the configuration that was actually used.

[07:43] Jim Amsden (IBM): Not clear what it should be - global config or local config for that resource.

[07:45] Jim Amsden (IBM): allows monitoring of config-unaware clients to see the requests and note what context they were using.

[07:45] Jim Amsden (IBM): allows client using global config to determine what local config was used to address

[07:47] Jim Amsden (IBM): could check that the GC hadn't changed without the client being made aware of it.

[07:48] Jim Amsden (IBM): we want config-unaware client behaviors at least predictable, fewer MAYs in the spec

[07:49] Jim Amsden (IBM): Airbus proposal suggest some awareness of configuration management, some tool would need to setup the default

[07:49] Jim Amsden (IBM): A way to read the default config would help this.

[07:50] Jim Amsden (IBM): Setting might want to be server, and/or user specification

[07:51] Jim Amsden (IBM): some implementations would want to require specifying a global config in order to get consistent resource versions

[07:51] Jim Amsden (IBM): So defaults on local configuration context may not help that much, might need to be a global default to address configurations across tools.

[07:52] Jim Amsden (IBM): Implies all tools would need to be global configuration aware - contribute to and use global configurations, not just their local Configuration-Context URI.

[07:52] Jim Amsden (IBM): May need to address some of this with committee note/guidance

[07:53] Jim Amsden (IBM): allow a URI to get the default config URI, could be global or local.

[07:53] Nick Crossley (IBM): A URI on the OSLC service

[07:54] Jim Amsden (IBM): Proposal: provide a property on the CCM service that provides access to the default config URI

[07:54] Nick Crossley (IBM): oslc_config:defaultConfiguration

[07:56] Jim Amsden (IBM): Action: Nick will raise an issue and provide a proposal.

[07:58] Jim Amsden (IBM): Action: Nick will raise an issue regarding providing Configuration-Context response header

[07:59] Jim Amsden (IBM): MUST would result in existing implementations becoming non-compliant, but they all are anyway since this is an editor's draft specification.

Meetings/Telecon2016.04.21 (last edited 2016-05-18 07:18:35 by ndjc)