Event details


  1. Scribe nomination
  2. Roll Call
  3. Approval of Meetings/Telecon2018.10.11 minutes

  4. Next meeting Meetings/Telecon2018.10.25

  5. Actions from the previous meeting
    • Martin to finish quality review of all core documents
    • Jim to do quality review of query spec
    • Nick to update config management spec to reflect decision in issue 183

    • Andrew to follow up on reconsideration of issue 9, including contacting Martin Pain

    • Jim to ask Chet about moving to Github - what is their opinion, what support/tools could they provide, etc.
    • All committee members should review new OSLC site and comments

  6. Topics
    • Paging in core spec - issues 141, 151 and 186.

  7. Other business

Voting Rights

Held by:







Chat transcript from room: oslc

[14:01] Martin Sarabura: Previous meeting minutes:
[14:03] Martin Sarabura: Feedback from Andrew: All TC members should review the discovery scenarios and provide comments and new scenarios action should have been in the list The action item on the website should have been: Review critical content issues that are blocking the website launch and help out with content or (better) pull requests. Martin Pain said it might take some for him to review my discovery scenarios & proposals and get back to me. So, please review the discovery scenarios without waiting for his feedback first. is up, not all committer emails & branches were migrated but we can fix it and rerun the script.
[14:06] Martin Sarabura: Jim report re steering committee feedback - let's hurry up and get migrated
[14:07] Martin Sarabura: Also, emphasis on blogs, wikis, etc to replace the content currently available on
[14:08] Martin Sarabura: A lot of dev work already done, isn't stuff that's being discovered
[14:14] Martin Sarabura: Martin scribe today
[14:14] Martin Sarabura: we have quorum...
[14:15] Martin Sarabura: Minutes accepted
[14:15] Martin Sarabura: action items from previous meeting: Martin to finish quality review of all core documents
[14:16] Martin Sarabura: Martin has additional questions
[14:16] Martin Sarabura: Paging question: On receiving a resource representation, OSLC Clients should check for the presence of an oslc:nextPage value to determine if the representation contains partial information about the resource. If the value is present, then paging is in effect and the representation contains partial information about the resource.
[14:17] Martin Sarabura: Do we need this paragraph, the 302 will tell you that the redirected URL contains oslc.paging or oslc.pageSize
[14:17] Martin Sarabura: section 4.11.5
[14:20] Martin Sarabura: When viewing a canonical URI it may not have the oslc.paging or pageSize parameters in the URI
[14:21] Martin Sarabura: Jim's other feedback still has to be folded into the document
[14:24] Martin Sarabura: Andrew: re paging, don't want to break semantics of redirects and LDP
[14:25] Martin Sarabura: Don't want to restrict ability to redirect via HTTP
[14:25] Martin Sarabura: LDP risk is that the URLs need to be parsed in order to conform to spec
[14:25] Martin Sarabura: Unfortunately this is acquired from the 2.0 spec
[14:26] Martin Sarabura: Andrew to have a look at the paging section
[14:27] Martin Sarabura: Query spec has many detailed conformance clauses also, is this OK?
[14:27] Martin Sarabura: Jim: Don't care
[14:28] Martin Sarabura: Andrew: re steering committee's response to email received
[14:29] Martin Sarabura: No guidance from steering committee on changing specs
[14:29] Martin Sarabura: Focusing specifically on "dry material" to see if we can make changes...
[14:30] Martin Sarabura: Are we OK with missing explanatory material? No actions agreed to at this time
[14:31] Martin Sarabura: Jim: Bring up to TC if you want to discuss further.
[14:32] Martin Sarabura: Feedback was that it's not a "user guide".
[14:32] Martin Sarabura: Andrew: Budget to hire technical writer?
[14:32] Martin Sarabura: After public review is probably counter-productive
[14:34] Martin Sarabura: Andrew: Version identifier in requests - needed for future versions
[14:34] Martin Sarabura: Need way to introduce breaking changes
[14:35] Martin Sarabura: Jim: Need to maintain compatibility for 3.0 otherwise we fail in fundamental purpose
[14:36] Martin Sarabura: OSLC 4.0+ is where we would be introducing breaking changes, potentially
[14:37] Martin Sarabura: Just need to be able to discover what's available on that server
[14:38] Martin Sarabura: Andrew: may need to consider binary protocol
[14:39] Martin Sarabura: Not 3.0, but looking forward we do need to be able to check version
[14:39] Martin Sarabura: Jim: Deal with it when it becomes necessary
[14:39] Martin Sarabura: Andrew: This increases cost down the road
[14:42] Martin Sarabura: Jim: Eg., link headers in response tells you it's a 3.0 server
[14:43] Martin Sarabura: Andrew: Introspection on content is more expensive
[14:43] Martin Sarabura: Jim: Doesn't save you anything since you still have to do the work of parsing the link headers
[14:45] Martin Sarabura: Jim: Raise an issue if we need it
[14:45] Martin Sarabura: Martin: If discovery doesn't tell you what to do, (gap in spec) then we probably need to fix discovery rather than introduce version number
[14:46] Martin Sarabura: Jim: Chet says go ahead and migrate to github
[14:47] Andrew Berezovskyi (KTH): Proposal: Migrate OSLC Core TC to GitHub in order to use a single infrastructure for all OSLC specification development activities, to provide a simpler, more efficient set of specification lifecycle management capabilities for the TC members, and to improve the external user experience.
[14:47] Martin Sarabura: Martin seconded
[14:47] Jim Amsden: +1
[14:47] Martin Sarabura: +1
[14:48] Andrew Berezovskyi (KTH): +1
[14:48] Martin Sarabura: Motion accepted
[14:48] Martin Sarabura: Jim to do quality review of query spec - some issues raised
[14:49] Martin Sarabura: Jim to ask Chet: done
[14:49] Martin Sarabura:
[14:51] Martin Sarabura: 4 scenarios
[14:52] Martin Sarabura: If you have link headers you should be able to discover everything
[14:53] Martin Sarabura: Rainy day: Non-OSLC front end
[14:54] Martin Sarabura: Jim: Not sure what problem well-known URI solves
[14:55] Martin Sarabura: Prior discussion indicated you need to know well-known URI rather than having one already in hand
[14:57] Martin Sarabura: Jazz apps use some form of well-known uri - starting with some URI you can infer the well-known URI
[14:58] Martin Sarabura: Root services document is plahying that role, has service provider properties, values are uRLs to Service provider catalogs
[15:00] Martin Sarabura: Should continue this discussion
[15:04] Martin Sarabura: Scenario: Martin to come up with scenario where implementer does not have access to the system
[15:04] Martin Sarabura: Meeting adjourned

Meetings/Telecon2018.10.18 (last edited 2018-10-25 11:51:07 by sarabura)