Event details


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

  4. Next meeting Meetings/Telecon2018.09.06

  5. Actions from the previous meeting
    • TBD
  6. Topics
  7. Other business

Voting Rights

Held by:







Chat transcript from room: oslc

[14:04] Jim Amsden: Jim scribe
[14:04] Martin Sarabura:
[14:05] Jim Amsden: minutes approved
[14:05] Jim Amsden: previous actions:
[14:05] Martin Sarabura:
[14:06] Jim Amsden: resource operations overview proposal from Andrew
[14:06] Martin Sarabura: Did andrew make a proposal?
[14:06] Martin Sarabura:
[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 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:
[14:58] Jim Amsden: we decided to defer the discussion to the above issue and wait for further input from David

Meetings/Telecon2018.08.30 (last edited 2018-08-30 15:19:59 by sarabura)