Draft minutes for OASIS CCM TC meeting on July 16th

[Nick Crossley <ncrossley@us.ibm.com>]

Here are the draft minutes for the OASIS CCM TC meeting on July 16th; these minutes may also be found at https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2015.07.16.

Nick.

Edited chat transcript from room: oslc-ccm 2015-07-16 GMT-08:00
[07:06] List of attendees: Bill Chown (Mentor Graphics), David Honey (IBM), Jim Amsden (IBM), Jim Ruehlin (IBM), Martin Sarabura (PTC), Nick Crossley (IBM), Peter Hack (IBM)
[07:06] Martin Sarabura (PTC): Martin scribe today
[07:07] Martin Sarabura (PTC): Minutes of previous meeting
[07:07] Nick Crossley (IBM): Previous meeting minutes: https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2015.07.02
[07:08] Martin Sarabura (PTC): Minutes approved

Core & Change Management Topics
[07:08] Martin Sarabura (PTC): Change management? Jim raised an issue - need resolution/guidance on 5 things
[07:09] Jim Amsden (IBM): https://issues.oasis-open.org/browse/OSLCCCM-12?jql=project%20%3D%20OSLCCCM%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
[07:09] Jim Amsden (IBM): Service Discovery: MUST support OSLC 3.0 discovery, MAY support Service Provider resource. Resource representation: Turtle: MUST, JSON: MUST, RDF/XML: SHOULD and XML: SHOULD for backward compatibility. OSLC-Core-Version header? Follow Core 3.0, but address v2 compatibility. Use dcterms:type and rdf:type? Reference to LDP PATCH method - not final, is it required?
[07:10] Martin Sarabura (PTC): Service discovery: Mostly just a note re changes in core v3
[07:11] Martin Sarabura (PTC): RDF/XML must for backward compatibility?
[07:11] Martin Sarabura (PTC): David: Guarantee compatibility with v2
[07:11] Martin Sarabura (PTC): Jim: Will make RDF/XML a MUST, also in core
[07:12] Martin Sarabura (PTC): Jim: Core version header?
[07:13] Martin Sarabura (PTC): Nick: History goes back to OSLC 1 and 2. Without header return OSLC 1 representations by default
[07:13] Martin Sarabura (PTC): For some IBM implementations
[07:14] Martin Sarabura (PTC): Jim: Doesn't it make sense that we should add v3 for consistency?
[07:15] Martin Sarabura (PTC): Jim: Will follow up with core team. Needed for 2.0 compatibility for change management at least
[07:16] Martin Sarabura (PTC): 3.0 server must respond with 2.0 header otherwise client will assume 1.0?
[07:16] Martin Sarabura (PTC): Nick: Clients need to send oslc 2 header - oslc 3 server with 2 client; it could just ignore and not send 1 representations
[07:17] Martin Sarabura (PTC): Jim: Will think about more
[07:17] Martin Sarabura (PTC): Nick: for server to server communication, server is client - server needs to send header otherwise may receive oslc 1 responses
[07:18] Martin Sarabura (PTC): Jim: Confusion re dcterms:type and rdf:type?
[07:19] Martin Sarabura (PTC): Many existing products rely on dcterms:type - should we require dcterms:type with text string as a convenience?
[07:20] Martin Sarabura (PTC): Nick: Reintroducing requirement for dcterms:type is problematic
[07:20] Martin Sarabura (PTC): Nick: Recommend leave as is and deprecate dcterms:type
[07:21] Martin Sarabura (PTC): Nick: Can add dcterms:type for compatibility with older drafts of oslc v2
[07:21] Martin Sarabura (PTC): Jim: ok
[07:21] Martin Sarabura (PTC): LDP patch?
[07:22] Martin Sarabura (PTC): Jim: Is there a reason to require PATCH in change management?
[07:23] Martin Sarabura (PTC): Nick: Config management not yet in current draft, IBM internally recommends using patch to update
[07:24] Martin Sarabura (PTC): Is it a problem to reference an incomplete standard?
[07:24] Martin Sarabura (PTC): Nick: Had this discussion during TRS
[07:24] Martin Sarabura (PTC): Tracked resource sets
[07:25] Martin Sarabura (PTC): May look at TRS or in accompanying index linked data provider document
[07:25] Martin Sarabura (PTC): some permutation of those magic words
[07:26] Martin Sarabura (PTC): Jim: Not sure why it needs to be called out in CM - eg PUT not called out
[07:26] Martin Sarabura (PTC): Jim: Core, added eTag for v2 compatibility
[07:27] Martin Sarabura (PTC): Jim: Even with PATCH you'd still want to use eTag

Configuration Management Topics
[07:27] Martin Sarabura (PTC): Need to define response that comes back with 202 Req accepted
[07:28] Martin Sarabura (PTC): HTTP defines 202 but doesn't define exact semantics of what comes back with it
[07:28] Martin Sarabura (PTC): David: Should include location of update
[07:29] Martin Sarabura (PTC): Nick: Not in current spec, also not included is client responsibilities
[07:30] Martin Sarabura (PTC): David: changes due to ldpc in baseline and stream
[07:30] Martin Sarabura (PTC): Nick: Plan to go through changes in more detail
[07:31] Martin Sarabura (PTC): Nick will contact Bill re how he wants to be brought up to speed re recent changes
[07:31] Martin Sarabura (PTC): Nick: Split document into a few docs
[07:32] Martin Sarabura (PTC): Doc for version management, configuration management
[07:32] Martin Sarabura (PTC): Global configuration doc not yet separated out - not sure it should be
[07:33] Martin Sarabura (PTC): Config management has some mentions of global config, open to review feedback whether it's worth breaking it out
[07:33] Martin Sarabura (PTC): Advantage of splitting out is that a local config provider spec is not distracted by references to global
[07:34] Martin Sarabura (PTC): Coming to conclusion that a second doc may be more difficult to read
[07:34] Martin Sarabura (PTC): Do know a couple of implementations of just version management
[07:35] Martin Sarabura (PTC): Config management implementations will have to read both, version management just the one document
[07:36] Martin Sarabura (PTC): Jim: If no compelling reason to separate, maybe should not.
[07:36] Martin Sarabura (PTC): Nick: Please read and comment
[07:36] Martin Sarabura (PTC): Content changes...
[07:37] Martin Sarabura (PTC): Use of types vs use of flag oslc/type immutable
[07:37] Martin Sarabura (PTC): tag
[07:37] Martin Sarabura (PTC): Better to use a type marker to distinguish baselines/sgtreams?
[07:38] Martin Sarabura (PTC): David: Issue of compatibility - older clients likely to require oslc mutable
[07:39] Martin Sarabura (PTC): Nick: Kept oslc mutable in vocabulary but not required - defined property for clients using earlier draft
[07:39] Martin Sarabura (PTC): Type allows features mutable does not - eg., which configs are acceptable as contributions
[07:40] Martin Sarabura (PTC): Subtype of stream or baseline could be acceptable, for example
[07:40] Martin Sarabura (PTC): Ties in better with extensions for accept
[07:41] Martin Sarabura (PTC): David: May have compatibility issue again
[07:41] Martin Sarabura (PTC): Explicit type vs mutable
[07:41] Martin Sarabura (PTC): Nick: Alternatives using actions
[07:41] Martin Sarabura (PTC): LDPC of all streams for a given baseline
[07:42] Martin Sarabura (PTC): Get container should return list of all streams contained by baseline
[07:42] Martin Sarabura (PTC): May delay implementation of GET, for now treat as factory
[07:42] Martin Sarabura (PTC): Posting to container creates a new baseline
[07:43] Martin Sarabura (PTC): Container for component should be GETable - return baselines and streams
[07:44] Martin Sarabura (PTC): Creation factor per baseline and per stream means don't need complicated semantics - clearer what's going on
[07:44] Martin Sarabura (PTC): Current draft of spec avoids use of actions - simplifieid creation semantics
[07:45] Martin Sarabura (PTC): David: Previously could have posted to component LDPC to create stream from stream (?)
[07:45] Martin Sarabura (PTC): Nick: Nothing preventing a server implementing the previous semantics
[07:46] Martin Sarabura (PTC): Nick: Component LDPC can be writable to support
[07:46] Bill Chown (Mentor Graphics)2: Nick: I continue to listen but cannot contribute. Please contact me offline for that catch-up and I will get other members of my team involved.
[07:47] Martin Sarabura (PTC): Nick - those are the main changes
[07:47] Martin Sarabura (PTC): Also clarified vocabulary around shape
[07:47] Martin Sarabura (PTC): Property tables constructed by re-spec _javascript_
[07:48] Martin Sarabura (PTC): Checked in tool which performs consistency checks - tool not yet complete, need to check that references to URIs are resolvable
[07:49] Martin Sarabura (PTC): David: dcterms has # on end - get whole document
[07:49] Martin Sarabura (PTC): Nick: Need to fetch http resource with content type rdf, and then find relevant RDF resource with hash URI
[07:49] Martin Sarabura (PTC): Utility written in java, checked in to core
[07:50] Martin Sarabura (PTC): Produces internally a Jena model
[07:50] Martin Sarabura (PTC): Prints out to stdout the result model
[07:50] Martin Sarabura (PTC): Maybe some day web front end
[07:51] Martin Sarabura (PTC): Contributors welcome
[07:51] Martin Sarabura (PTC): Moved stable to point to new version - please review and comment on structure and content
[07:52] Martin Sarabura (PTC): Working on getting spec to state where it's reviewable by outside participants IETF
[07:52] Martin Sarabura (PTC): Set target of next meeting, July 30, to hold review of changes to spec. Will send out notice prior to meeting
[07:53] Martin Sarabura (PTC): Not yet ready for public review but good internal review point
[07:54] Martin Sarabura (PTC): David: Use JIRA to handle comments? Nick: Either is fine - JIRA or email. Will raise JIRA issue to capture streamed discussion
[07:55] Martin Sarabura (PTC): Nick: One other content change, discussed last time, extra triples that describe multiple matches in case of component skew, moved out to separate resource with a link header to that resource
[07:56] Martin Sarabura (PTC): Action: Nick to send out notification to mailing list to review
[07:57] Martin Sarabura (PTC): No other business, meeting adjourned