Scribe
- Martin Sarabura
Attendees
- Andrew Berezovskyi
- Jim Amsden
- Martin Sarabura
Resolutions
- 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.
Actions
- Andrew to review the paging section in the overview document
- Jim to do quality review of query spec
- Martin to add scenario to list of scenarios related to well-known entry point
Chat transcript from room: oslc
[14:01] Martin Sarabura: Previous meeting minutes:
https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.10.11
[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. https://github.com/berezovskyi/oslc-core 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 open-services.net migrated
[14:07] Martin Sarabura: Also, emphasis on blogs, wikis, etc to replace the content currently available on open-services.net
[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:
https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/oslc-core.html 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:
https://docs.google.com/document/d/1qczVGQXNdv8wXf-hilh8cgcTVOOWvmA9TWVogW5qGKU/edit
[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
Dr. Martin Sarabura
Technical Fellow, Enterprise Architecture Group
+1 (519) 502-4819
msarabura@ptc.com
ptc.comâ