OSLC Core TC Minutes September 17, 2015

Minutes

Chair 

Martin Sarabura (PTC) 

Scribe 

Martin Sarabura (PTC) 

Attendees 

David Honey (IBM) 

Harish (SoftwareAG) 

Jim Amsden (IBM) 

Martin Sarabura (PTC) 

Nick Crossley (IBM) 

Regrets 

Ian Green 

Martin Pain 

Resolutions 

·        
Any of the OSLC3 discovery capabilities may be utilized on
ServiceProviderCatalog or
ServiceProvider resources

Open oslc:details to content negotiation - no longer restricted to just HTML 

Close issue 9 (bootstrapping discovery) for lack of standardizable approach 

Actions 

Chat transcript from room: oslc 

[07:06] Martin Sarabura (PTC): Martin volunteers to be scribe

[07:06] List of attendees: David Honey (IBM), Harish (SoftwareAG), Jim Amsden (IBM), Martin Sarabura (PTC), Nick Crossley (IBM)

[07:07] Martin Sarabura (PTC): Minutes from Sep 3 meeting accepted

[07:08] Martin Sarabura (PTC): Ballot 9 expired with insufficientvotes

[07:09] Martin Sarabura (PTC): Issue 29 not submitted for electronic ballot due to outstanding issue on ldpc for spc and sps

[07:11] Martin Sarabura (PTC): Issue 20 coming to common agreement - already solved?

[07:11] Martin Sarabura (PTC): Jim: Do we need to find affected parties?

[07:12] Martin Sarabura (PTC): Nick: Why is 29 affected by ldpc question?

[07:12] Martin Sarabura (PTC): Jim: Nothing more required if it is an ldpc

[07:13] Martin Sarabura (PTC): Nick: Changing the resource shape of the catalog by adding an optional property - the selection dialog

[07:14] Martin Sarabura (PTC): David: W3C: No such thing as an LDP property

[07:15] Martin Sarabura (PTC): Nick: For compatibility , spc MAY be LDPC, not MUST

[07:16] Martin Sarabura (PTC): Jim: Client does GET on service provider, doesn't care whether it is an ldpc

[07:18] Martin Sarabura (PTC): Nick: Does this feature need to be tied to be an LDPC?

[07:18] Martin Sarabura (PTC): Feature is part of the RDF anyway, property is still there

[07:19] Martin Sarabura (PTC): Jim: If sp is not an ldpc and we want user selection mechanism, then we have to add dialog to shape

[07:19] Martin Sarabura (PTC): Nick: Even if it were an ldpc, you would add it anyway

[07:20] Martin Sarabura (PTC): Jim: ldp discovery says it must be there

[07:20] Martin Sarabura (PTC): Either way property is being added (ldpc or not)

[07:20] Martin Sarabura (PTC): So this issue is not dependent on LDPC question

[07:22] Martin Sarabura (PTC): Nick: spc is the real issue - already plan to choose a service from the provider

[07:23] Martin Sarabura (PTC): David: If type indicates it is a spc then it may have the dialog in ths shape

[07:25] Martin Sarabura (PTC): Nick: With 2 different specs, all of which influence a kind of resource, then the resource shape that the provider generates should contain the
 properties required by both specs. 

[07:26] Martin Sarabura (PTC): David: Proposal is to add to spc and sp the selection dialog capability

[07:27] Martin Sarabura (PTC): Clients that don't understand will simply ignore

[07:28] Martin Sarabura (PTC): Original issue discussed spc not sp - in the interest of keeping spec cleaner, do we keep the spec consistent and provide for both possibilities

[07:29] Martin Sarabura (PTC): Unlikely that we'll be creating new services - that would be a property of a different type

[07:30] Martin Sarabura (PTC): Multiple dialogs for the same type - can't disambiguate. That's already handled on service

[07:32] Martin Sarabura (PTC): Creating a new service is like implementing a new domain

[07:32] Martin Sarabura (PTC): Each service usually corresponds to a new oslc domain

[07:32] Martin Sarabura (PTC): Not typically something you can do dynamically

[07:33] Martin Sarabura (PTC): Jim: As we move towards more dynamic implementations, this could be possible

[07:34] Martin Sarabura (PTC): Jim: No particular reason to restrict this.

[07:35] Martin Sarabura (PTC): Nick: Provider can always add more properties, with the proposal as written nothing to prevent adding dialog to shape

[07:37] Martin Sarabura (PTC): Proposal is to add to spc and sp the selection dialog capability

[07:37] David Honey (IBM): +1

[07:37] Nick Crossley (IBM): +1

[07:37] Martin Sarabura (PTC): +1

[07:37] Harish (SoftwareAG): +1

[07:37] Jim Amsden (IBM): +1

[07:38] Martin Sarabura (PTC): Accepted

[07:38] Martin Sarabura (PTC): Jim: Need to update the issue to reflect this change before closing it

[07:38] Martin Sarabura (PTC): Note proposal did not include creation

[07:39] Martin Sarabura (PTC): Nick: Likely would go through separate path in UI

[07:39] Martin Sarabura (PTC): Jim: Under the covers it could be a POST to the factory

[07:40] Martin Sarabura (PTC): Jim: Should we simply say that OSLC v3 discovery MAY apply to both spcs and sps

[07:40] Martin Sarabura (PTC): No restriction on discovery anyway

[07:42] Martin Sarabura (PTC): Nick: Add to spc and sp any of the possibilities that appear in services

[07:48] Martin Sarabura (PTC): Primarily we are allowing a server to create whatever hierarchy is desired

[07:48] Martin Sarabura (PTC): Nothing's changing in existing model - simply generalizing

[07:49] Martin Sarabura (PTC): David: There may be unintended consequences

[07:50] Martin Sarabura (PTC): Jim: Mixing meta-level constraints into the implementation tends to lead to problems

[07:50] Martin Sarabura (PTC): Nick: One of complaints of v2 was complexity of discovery

[07:51] Martin Sarabura (PTC): Jim: Goes beyond just simplicity, also formalizes the possibility of more dynamic creation

[07:51] Jim Amsden (IBM): That is any of the OSLC3 discovery capabilities may be utilized on
ServiceProviderCatalog or
ServiceProvider resources.

[07:52] Nick Crossley (IBM): +1

[07:52] Martin Sarabura (PTC): +1

[07:52] David Honey (IBM): +1

[07:52] Harish (SoftwareAG): +1

[07:52] Martin Sarabura (PTC): Note: vote is on the statement that preceeded vote

[07:53] Jim Amsden (IBM): +1

[07:55] Martin Sarabura (PTC): Next: issue 20
https://issues.oasis-open.org/browse/OSLCCORE-20

[07:55] Martin Sarabura (PTC): Service provider should describe domain/scope

[07:58] Martin Sarabura (PTC): David: Don't want to solve this problem on something that is optional. If somebody is able to GET using rdf/xml then they know what they're looking
 for 

[07:59] Martin Sarabura (PTC): If we change the description of oslc-details then client can look at rdf of that resource

[08:01] Martin Sarabura (PTC): Non-normative recommendation that if server can return rdf that it include refereces to other RDF resources

[08:02] Martin Sarabura (PTC): Use oskc:details to link from the sp to the vendor=specific resource

[08:02] Martin Sarabura (PTC): Last two comments on Martin Pain's 19-aug entry

[08:04] Martin Sarabura (PTC): Should we be standardizing any content on oslc:details?

[08:04] Martin Sarabura (PTC): Nick: Just not require that oslc:details only point to html

[08:06] Martin Sarabura (PTC): Proposal: Open oslc:details to content negotiation

[08:06] David Honey (IBM): +1

[08:06] Nick Crossley (IBM): +1

[08:06] Martin Sarabura (PTC): +1

[08:07] Jim Amsden (IBM): TC voted to resolve this issue by allowing oslc:details to be subject to content negotiation, it is no longer restricted to HTML.

[08:07] Harish (SoftwareAG): +1

[08:07] Jim Amsden (IBM): +1

[08:07] Martin Sarabura (PTC): resolution passed

[08:14] Martin Sarabura (PTC): Next issue: 9
https://issues.oasis-open.org/browse/OSLCCORE-9

[08:16] Martin Sarabura (PTC): Nick: Don't understand why we shouldn't add extra vocabularies

[08:16] Martin Sarabura (PTC): Jim: Perhaps statement applies more to this specific scenario

[08:17] Martin Sarabura (PTC): Jim: Servers may provide a link header whose rel is resource discovery root

[08:18] Martin Sarabura (PTC): Jim: Propose use OPTIONS * for server - may provide a list of discovery resources

[08:18] Martin Sarabura (PTC): David: Is there any content negotiation involved in an OPTIONS request?

[08:20] Jim Amsden (IBM):
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

[08:21] Martin Sarabura (PTC): Here we have a candidate for providing a body to the OPTIONS request

[08:22] Martin Sarabura (PTC): Jim: Use OPTIONS * to locate service provider catalog

[08:22] Martin Sarabura (PTC): David: Is this easy to implement?

[08:23] Martin Sarabura (PTC): Nick: Typical web server running few applications, web server knows nothing about how to respond

[08:24] .wellknown has exactly the same issue

[08:25] Martin Sarabura (PTC): Nick: Don't seem to have a workable solution

[08:25] Martin Sarabura (PTC): Jim: Compromise: Most servers do know something about what services they're hosting

[08:26] Martin Sarabura (PTC): OPTIONS * already standard, nothing stopping server from returning whatever it wants.

[08:26] David Honey (IBM): JTS is simply another context root. It's not at "/" it's at "/jts".

[08:27] Martin Sarabura (PTC): Jim: Do nothing for now - we don't have a good solution

[08:29] Martin Sarabura (PTC): Nick: Have made a number of improvements to shape-checker tool, produces semi-readable output

[08:30] Martin Sarabura (PTC): Used annotations on source code to describe error msgs

[08:31] Martin Sarabura (PTC): Proposal: Close the issue on bootstrapping discovery

[08:31] David Honey (IBM): +1

[08:31] Nick Crossley (IBM): +1

[08:31] Jim Amsden (IBM): +1

[08:31] Harish (SoftwareAG): +1

[08:31] Martin Sarabura (PTC): +1