Minutes from May 28 meeting

Actions

Martin S - Determine how we can find out which MAY/SHOULD aspects of v2.0 are expected by 2.0 clients.

Chat transcript from room: oslc

ian green (ibm): List of attendees: David Honey (IBM), Harish (SoftwareAG), Jim Amsden (IBM), Martin Pain (IBM), Martin Sarabura (PTC), Nick Crossley (IBM), anonymous, ian green (ibm)

ian green (ibm): proposed to accept minutes. accepted

ian green (ibm): Jim recommending additional calls to cover outstanding items.

ian green (ibm): Discussion about extending calls to 90mins.

ian green (ibm): Agreement that additional informal "working" meetings also desirable. Do these meetings need to be minuted?

ian green (ibm): These additional meetings report back to TC meeting, where any minutes, voting etc. must take place.

ian green (ibm): Same conference line can be used for interim meetings

ian green (ibm): as for TC call.

ian green (ibm): Agenda item: Issue 9 - Bootstrapping discovery.

ian green (ibm): (https://issues.oasis-open.org/browse/OSLCCORE-9)

ian green (ibm): Jim: 2.0/3.0 compatibility has broad implications for 3.0 discovery, which we need to understand before we make proposals for 3.0

ian green (ibm): David: why did we move away from 2.0 discovery?

ian green (ibm): Summary of motivation that 3.0 discovery should be more flexible and dynamic "in style" than 2.0 catalogue.

ian green (ibm): Idea was that service catalogue was perhaps "old fashioned" and that LDP concepts could offer a more modern approach

ian green (ibm): Nick points out that 2.0 spec requires that future versions are compatible.

ian green (ibm): Observation that 3.0 server could potentially provide more than one way to discover services

ian green (ibm): David: could TRS be used to reflect changes in discovery documents

ian green (ibm): Jim: (refocussing) do we want 3.0 to be compatible with 2.0, Nick: and what does compatible mean.

ian green (ibm): Nick: a 2.0 client should work with a 3.0 server

ian green (ibm): Or, do we want compatibility to be easy to achieve, rather than required by the spec.

ian green (ibm): Is such a converter feasible (eg simple query)

ian green (ibm): MartinP: Burden of 2.0 was catalogue, query etc. Desirable for 3.0 to not place such burden on implementors

ian green (ibm): Nick raises the point of oslc:usage which seems to not have a corresponding facility for client to decide which LDPC to use

ian green (ibm): MartinS: 2.0 spec does not REQUIRE anything by way of discovery. Thus 3.0 need not provide 2.0 discovery, and remain compatible.

ian green (ibm): Jim: is this merely legalese?

ian green (ibm): Will we hurt oslc perception by taking this line?

ian green (ibm): DavidH: Are these 2.0 MAYs defacto MUSTs

ian green (ibm): Adapter could offer LDPCs which contain 2.0-like catalogue resources

ian green (ibm): MartinP describes model in which 3.0 exposes a 2.0 facade.

ian green (ibm): Circling back to the statement "what is compatibility"? Do we need to cover all possibilities, or only some subset?

ian green (ibm): No consensus reached on compatibility. Nick suggests taking this to the OSLC steering cttee

ian green (ibm): Jim: are we in a position to vote on this?

ian green (ibm): Jim: we can inform this with an analysis of dependencies that current 3.0 specs/drafts have on 2.0-like services

ian green (ibm): Jim: can't base compatibility on what is hard to implement - needs to be based on need

ian green (ibm): table this discussion; need more concrete position before we can vote

ian green (ibm): Compatibility reqs can be found at: https://issues.oasis-open.org/browse/OSLCCORE-10

ian green (ibm): nope, i think that is the wrong link.

ian green (ibm): Nick: we have no record of who is "using" 2.0, so near impossible to assess impact of compatibility loss.

Nick Crossley (IBM): https://issues.oasis-open.org/browse/OSLCCORE-5

ian green (ibm): MartinS: can we solicit feedback from community - perhaps asking specific communities known to be interested in OSLC

ian green (ibm): Next meeting June 11th (90 mins)

ian green (ibm): Meeting adjourned

oslc-core message