Event details


  1. Scribe nomination
  2. Roll Call
  3. Approval of March 3rd minutes

  4. Next meeting March 31, 2016
  5. Actions from the previous meeting
    • Nick and Jim to check whether oslc:range is included in the ReSpec tables

    • Nick and Ian to discuss cardinality and structure of service providers and services and their LDPCs
    • Nick, Jim and Ian to discuss language in 2nd last paragraph of Section 6.2 of

    • Martin to submit an electronic vote for the resolution of issue 60: For plain literals with language tags, single-valued means there is only one literal value for any given language tag.

    • Martin to submit an electronic vote for proposal to go to public review once remaining issues are resolved.
  6. Topics
  7. Other business

How to prepare for this meeting

  1. Encourage all TC members and external stakeholders to review all documents

Voting Rights

Held by:








Chat transcript from room: oslc [10:09] Martin Sarabura (PTC):

[10:09] ian green: Minutes from 03/03 accepted.

[10:11] Martin Sarabura (PTC): Nick and Jim to check whether oslc:range is included in the ReSpec tables

[10:11] ian green: Action item completed

[10:11] Martin Sarabura (PTC): Nick and Ian to discuss cardinality and structure of service providers and services and their LDPCs

[10:15] ian green: Ian and Nick have not discussed

[10:18] ian green: Nick: Keep action open- we can address this with some examples in a 3.0 Primer, perhaps

[10:19] ian green: Jim: it is possible for a server to choose a close correlation between Service discovery and LDPCs or it can have entirely different layout. No need to impose constraints.

[10:20] ian green: Martin: remove action, but keep issue open.

[10:21] ian green: Action item "Section 6.2" wording.

[10:22] ian green: Proposal on mailing list to remove 2nd last paragraph.

[10:22] ian green: Martin: no objections heard to this proposal

[10:22] Martin Pain (IBM): Martin Pain joined (apologies for being late)

[10:24] ian green: Nick: some concern over a pure "conjunctive" interpretation because of the query & factory cases.

[10:24] Jad El-khoury (KTH): Hi! I have just joined.

[10:24] Martin Sarabura (PTC): Hi Jad

[10:25] ian green: Nick: should we additionally edit the first paragraph to reflect the subtlety?

[10:25] ian green: Jim: will craft a slightly different paragraph.

[10:27] ian green: Jim will update the proposal in

[10:28] ian green: Martin and Jad joined the call.

[10:28] ian green: Martin: issue proposal has been accepted

[10:29] ian green: Martin: f/b from Chet that mean we're not able to go to public review

[10:29] Martin Sarabura (PTC): Chet: what do we need to have in the folders in order for the HTML to appear properly

[10:30] ian green: Jim: and the svn are not joined. "Publish" is self-contained copy.

[10:32] ian green: Nick: to clarify. Need to publish generated HTML and PDF (from respec). For raw HTML, we would need respec

[10:32] ian green: either way, we need css, images etc

[10:37] ian green: Jim: discuss with Chet details of url/file naming

[10:38] ian green: Jim and Nick to explore, in conjunction with Chet, to see how best to realize the OASIS requirements

[10:43] ian green: Nick: outlining how changes to respec will have to be adopted by existing core specs

[10:43] ian green: Jim: another action: Jim and Nick to work on a procedure for publishing

[10:44] ian green: Martin: when we have this bundle, we need to have a vote, before delivery to Chet

[10:44] Jim Amsden (IBM): [ ] Jim to send questions to Chet

[ ] Nick will update ReSpec on his private branch to get the Config Spec to align with Chets OSLC templates.

[ ] After some number of iterations, Nick will checkin his ReSpec and Config Management spec and will list the changes that have to be made so that specifications use the updated ReSpec properly

[ ] Jim will apply those changes to the Cores

[ ] Jim and Nick will work to come up with a procedure for publishing the documents for CSD, CSPRD, or any other published version.

[10:46] ian green: MartinS: anything else to consider for publish?

[10:47] ian green: Jim: yes; change history section has not been maintained; scm has commit log, but this might not be suitable for publication

[10:48] ian green: Nick: suggests we only need change history for from first public review

[10:49] ian green: Nick: we ought to have a non-normative document which decribes differences between v2 and v3

[10:50] ian green: MartinS: supports suggestion to maintain change history post public review

[10:52] ian green: Jim: we can avoid having a separate cttee note, but an alternative is to put this into the main spec.

[10:53] ian green: Jim: confirm: change history will not have anything until public review.

[10:54] ian green: MartinS: no objections

[10:55] ian green: Jim: we can refer to the history without linking to it from the spec

[10:56] ian green: MartinS: Arthur Ryman to be given credit in the documents

Meetings/Telecon2016.03.17 (last edited 2016-03-20 22:34:22 by sarabura)