[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OSLC Core TC Minutes September 17, 2015
Minutes
Chair
Scribe
Attendees
Regrets
Resolutions
·
Any of the OSLC3 discovery capabilities may be utilized on
ServiceProviderCatalog or
ServiceProvider resources
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]