Event details


  1. Scribe nomination
  2. Roll Call
  3. Approval of Mar 15 minutes

  4. Next meeting Mar 29, 2018

  5. Actions from the previous meeting
    • Jim to finish the edit updates still pending on the multi-part core documents
    • Martin to update wiki page to reflect the timing of our project plan
  6. Topics
    • TBD
  7. Other business

Voting Rights

Held by:








Chat transcript from room: oslc

Jim Amsden: Last meeting minutes:
Jim Amsden: Missing actions from previous minutes:
Jim Amsden: Action:Nick: raise an issue on rebase handling
Jim Amsden: Action: Nick: raise an issue on eTags support in TRS
Jim Amsden: both of these issues are completed
Jim Amsden: Action: Martin: Schedule for Core specs - suggests waiting for v3 implementation from PTC (open source), since that would be a good thing to have as a reference implementation
Jim Amsden: Martin will need OSLC Core 3.0 CS02 done, and possibly a CS01 on OSLC query published at the same time
Jim Amsden: Nick would like further discussion with Martin and PTC on new version resolution algorithm (taking it out of the spec for greater flexibility)
Jim Amsden: Proposal has been updated to be at least deterministic,
Jim Amsden: Proposed spec is in draft spec, need vote to approve. Vote pending additional discussion.
Jim Amsden: TRS eTag support raises potential vocabulary issues
Nick Crossley (IBM):
Jim Amsden: would like to introduce a way for clients and servers to verify trs feeds.
Jim Amsden: in existing TRS spec, there is support for PATCH events that contain eTags for before and after states - so client can know if they need to do a GET or can just update from the PATCH
Jim Amsden: specify eTags in Base and in an create or modification event, not just PATCH
Jim Amsden: a tool could then verify the TRS feed is complete and correct on the server, and for the client to verify it has the right states of the resources
Jim Amsden: need a predicate to describe the eTag.
Jim Amsden: could use existing vocabulary term for PATCH event, beforeeTag, aftereTag reflects the eTag the resource should have at a point in time
Jim Amsden: alternative, create trs:etag predicate.
Jim Amsden: not clear why PATCH used a separate namespace.
Nick Crossley (IBM): trs_patch:afterEtag and trs_patch:beforeEtag
Jim Amsden: An OSLC server can apply changes to a resource, and update the eTag, but if it doesn't change public properties, it may not create a change event and may not update the eTag
Jim Amsden: the meaning of the state of a resource corresponding to the base is not entirely clear
Jim Amsden: some servers construct a new base on rebase - and represent the set of tracked resources at a point in time.
Jim Amsden: this was the original intent. eTag in the base would represent the state of the resource at the point in time in which the base was created
Jim Amsden: and corresponds to the cutoff event
Jim Amsden: There are however other implementations where the base is incrementally updates based on creation and deletion events.
Jim Amsden: Base at that point does not correspond to a specific points in time.
Jim Amsden: so a particular entry in the base may not have any corresponding change event, or there could be older or newer change events with the base being somewhere in the middle
Jim Amsden: GET of a resource at some point in time might return an eTag different that what is in the base.
Jim Amsden: afterETag doesn't represent the current state of a resource, rather the state after the particular change envent
Jim Amsden: prefer to not use trs_patch namespace in the base TRS spec.
Jim Amsden: What is the meaning of eTag in TRS base
Jim Amsden: hopefully could be used to verify the TRS feed.
Jim Amsden: could be an optional property in the base, to allow servers to provide eTag data in a known property.
Jim Amsden: what would it mean?
Jim Amsden: Action: Nick: write a proposal for new vocabulary term for oslc_trs:etag (or something) with text describing what it means
Jim Amsden: and some use cases on how it would be used by TRS consumers and providers

Meetings/Telecon2018.03.22 (last edited 2018-04-04 23:36:19 by sarabura)