Correction on previous minutes: Minutes were for Aug 9, not Aug 2. The subject of the email was incorrect, otherwise nothing changed.
I have updated the
action item on the OASIS site to reflect the current conference call code.
Scribe
- Jim Amsden (IBM)
Attendees
- Jim Amsden (IBM)
- Martin Sarabura (PTC)
- Nick Crossley (IBM)
- Ian Green (IBM)
Resolutions
- Accept the proposal from issue 178
Actions
- Jim to merge the change from issue 178 into the core spec
- Martin to discuss with PTC team possibility of implementing a generic HTML finder as a React component in OSLC4JS
Chat transcript from room: oslc
[14:04] Jim Amsden: Jim scribe
[14:04] Martin Sarabura: https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2018.08.09
[14:05] Jim Amsden: minutes approved
[14:05] Jim Amsden: previous actions:
[14:05] Martin Sarabura: http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/csprd03/part1-overview/oslc-core-v3.0-csprd03-part1-overview.html#resourceOperations
[14:06] Jim Amsden: resource operations overview proposal from Andrew
[14:06] Martin Sarabura: Did andrew make a proposal?
[14:06] Martin Sarabura: https://issues.oasis-open.org/browse/OSLCCORE-178
[14:10] Jim Amsden: Client preserves properties on GET before PUT
[14:11] Jim Amsden: but PATCH allows the client to tell the server to only update the specified properties, and not delete any others (which PUT would do)
[14:11] Jim Amsden: Should we specify a specific 4xx status code if the server refuses the PUT.
[14:12] Jim Amsden: Martin: proposes to accept the proposal in the issue
[14:12] Jim Amsden: Nick seconded
[14:12] Jim Amsden: +1
[14:12] Nick Crossley (IBM): +1
[14:13] Martin Sarabura: +1
[14:13] ian green: +1
[14:13] Jim Amsden: Motion carriesAction: Jim to apply the proposed changes to core 3.0 overview spec.
[14:15] Martin Sarabura: Minor updates have been made to core as we've found a few things
[14:15] Martin Sarabura: Have not applied the respec changes to mark all the normative sections, plus conformance section
[14:16] Martin Sarabura: Core specs not implemented all the same way, some use older technique. Finding paragraphs with MAY/MUST/SHOULD should be done
[14:16] Martin Sarabura: and mark them as conformance clauses
[14:17] Martin Sarabura: Probably don't want to do committee spec until a little further along with query/TRS in case there are additional impacts - having draft docs from David and Nick will help
[14:17] Martin Sarabura: Had committee spec for core, need to do another one, need to think about what's next - need statements of use to get promoted to OASIS standard
[14:18] Martin Sarabura: Without any implementations of OSLC v3 and no conformance test suites the quality of standard and adoption could be compromised
[14:18] Martin Sarabura: Jim working on getting OSLC4JS implementation going
[14:19] Martin Sarabura: Express middleware component to expose LDP services
[14:19] Martin Sarabura: Mostly done, need to finish a few things like POST
[14:20] Martin Sarabura: OSLC service is another Express component, needed still
[14:20] Martin Sarabura: OSLC part is likely simpler once LDP is done
[14:22] Jim Amsden: PTC is planning to contribute to OSLC4JS with a target release sometime in December
[14:22] Jim Amsden: PTC needs to build and OSLC 3.0 server, but will also need an OSLC 3.0 client to test it
[14:23] Jim Amsden: current OSLC4JS client uses OSLC 2.0 style discovery, but could easily be updated to also support OSLC 2.0 incremental discovery using Link headers.
[14:24] Jim Amsden: i.e., OSLC 3.0 incremental discovery
[14:30] Jim Amsden: we may also wish to work on the proposed oslc-browser that is part of OSLC4JS, a generic RDF resource browser that can use OSLC discovery to find resources and navigate their object properties.
[14:31] Jim Amsden: Query: David will try to provide an updated spec for TC review next week.
[14:32] Jim Amsden: What does GET on queryBase URL mean?
[14:35] Jim Amsden: we already decided to merge property tree and graph pattern.
[14:35] Jim Amsden: as the union of the two.
[14:35] Jim Amsden: if each are optional, and by default either one provides nothing
[14:36] Jim Amsden: then the GET on a queryBase URI would be nothing, not everythings.
[14:36] Martin Sarabura: Didn't address Jim's other point to get WHERE true
[14:39] Jim Amsden: oslc.where syntax requires left and right operands. The right operand can be a literal, but not the left. Its not clear any _expression_ could be created that is where=true to ensure all resources are returned
[14:39] Jim Amsden: Note if the queryBase is an LDPC, then GET on the URI would return all members.
[14:40] Jim Amsden: Note: most jazz.net implementations do return all members on GET queryBase
[14:42] Jim Amsden: we probably don't need to addres where=true
[14:42] Jim Amsden: advisable to define GET queryBase, but might be acceptable to leave it undefined as in OSLC 2.0 to avoid creating any incompatibility issues.
[14:43] Jim Amsden: or we could use SHOULD not MUST on GET queryBase
[14:46] Jim Amsden: Proposal: Add the following statement to OSLC Query Spec: OSLC Servers SHOULD support GET on the queryBase URI, and the result should return all members, as there was an oslc.where class that evaluated to true for all members.
[14:48] Jim Amsden: Nick: should it return nothing?
[14:49] Jim Amsden: This assumes that queryBase would generally be an LDPC
[14:49] Jim Amsden: this is something we thing should be encouraged
[14:50] Jim Amsden: Nick: doesn't object, but isn't sure this is needed
[14:51] Jim Amsden: There could also be a performance impact on the server.
[14:52] Jim Amsden: Should the server be able to decide
[14:52] Jim Amsden: Servers can page
[14:53] Jim Amsden: LDPC does not specify any query language, so there is no way to limit the performance issues with GET on very large LDPCS
[14:56] Jim Amsden: clients have options for dealing with large result sets by using paging or adding an oslc.where clause. If servers don't support either, then GET on a queryBase would have to return all members in order to be minimally useful
[14:58] Martin Sarabura: https://issues.oasis-open.org/projects/OSLCCORE/issues/OSLCCORE-179
[14:58] Jim Amsden: we decided to defer the discussion to the above issue and wait for further input from David
Dr. Martin Sarabura
Technical Fellow, Office of Research & Architecture
+1 (519) 502-4819
msarabura@ptc.com
ptc.comâ