[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for 1 May 2014
Minutes
Chair
Arnaud J Le Hors (IBM)
Scribe
Jim Conallen (IBM)
Attendees
Arnaud J Le Hors (IBM), David Green (Tasktop Technologies),
Ian Green (IBM), Jim Conallen (IBM), John Arwe (IBM), Martin Pain (IBM),
Nick Crossley (IBM), Robin Cover (OASIS), Sam Padgett (IBM), Steve Speicher
(IBM), Lonnie (Sodius) Regrets: Harish Krishnaswamy (Software AG)
Resolutions
Chat transcript from room: oslc
2014-05-01 GMT-08:00 (Timestamps below are US Pacific)
Roll Call
[07:56] Arnaud J Le Hors (IBM): Attendees: Arnaud J Le Hors (IBM) David Green (Tasktop Technologies) ian green (IBM) jim conallen (IBM) John Arwe (IBM) Martin Pain (IBM) Nick Crossley (IBM) Robin Cover (OASIS) Sam Padgett (IBM) Steve Speicher (IBM) Lonnie (Sodius)
Approval of minutes of last meeting (April 3)
[07:10] jim conallen (IBM): Arnaud proposes aceptance of minutes SteveS seconds.
[07:10] jim conallen (IBM): minutes approved by all
[07:10] John Arwe (IBM): those minutes are at https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.04.03#Minutes
Vocab URIs
[07:12] jim conallen (IBM): to help review specs we should assign one or two people to review in detail
[07:13] Robin Cover: Steve's Wiki page: https://wiki.oasis-open.org/oslc-core/VocabStableURINotes
[07:13] jim conallen (IBM): Steve: we should time box this topic. Arnaud agrees
[07:16] jim conallen (IBM): 1.5 years ago, when look for places for standardization considering problems of having a lot of open-services.net terms, a new standards body URI would break a lot of things
[07:18] jim conallen (IBM): main scenarios: existing vocabs with additions and new vocabs
[07:20] jim conallen (IBM): steve: using redirection on old vocab terms is reasonable since it should not be hit that often
[07:20] jim conallen (IBM): optimizing get is not a high priority
[07:20] John Arwe (IBM): It's not just queries either. Those NSURIs are part of the client interface that our products MUST maintain compatibly. Any third party writing to the REST APIs would also be forced to change.
[07:22] jim conallen (IBM): Ian: this issue is no different from server rename as we know is a difficult problem - not as simple as just re-directs.
[07:22] jim conallen (IBM): Arnaud: many standards bodies go through this same problem.
[07:24] jim conallen (IBM): Time up for this discussion. Steve asks everyone to contribute to the wiki and we will dedicate another meeting to this.
[07:25] jim conallen (IBM): issues include transfering domain ownership to oasis
[07:28] jim conallen (IBM): arnaud: there is a history of significant issues with XML namespaces in IBM - the web site was overloaded and they put a block on all IBM addresses.
Next call
[07:30] jim conallen (IBM): Arnaud: is May15th good for next call?
[07:30] jim conallen (IBM): noone objects
Resource Preview / JSON -LD discussion
[07:31] Sam Padgett (IBM): https://wiki.oasis-open.org/oslc-core/CompactResourceDiscovery
[07:31] jim conallen (IBM): Sam: new draft uploaded, wiki link sent out - not much feedback
[07:31] Nick Crossley (IBM): Lastly on namespace renaming - we do have end users writing queries with the OSLC namespaces - changing those would require users to update their queries - so it's not just legacy software that would have to change.
[07:33] jim conallen (IBM): Sam provides overview of three options, with third being his preferred
[07:34] Sam Padgett (IBM): http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/resource-preview.html
[07:37] jim conallen (IBM): Sam: kept 200 vs 209, since 209 is still provisional
[07:41] jim conallen (IBM): Steve: we should summarize on the page the direction we want to go.
[07:43] jim conallen (IBM): current draft reflects this dirction (optinon 3)
[07:43] jim conallen (IBM): Arnaud: the stick is in the ground with the current draft spec. the wiki just provides info on the alternatives that were considered
[07:43] John Arwe (IBM): section 5.1 of the draft
[07:43] Steve Speicher (IBM): https://wiki.oasis-open.org/oslc-core/CompactResourceDiscovery#Conclusion
[07:49] jim conallen (IBM): some discussion on compact resource uri being different than resource uri
[07:49] jim conallen (IBM): current wording is that they should not be
[07:51] jim conallen (IBM): Sam: there are cases where some properties (dcterm:title) have different values in the compact rendering compared to resource. Ian agrees if this case should be different URI
[07:51] John Arwe (IBM): 5.1 bullet 3 is the new MUST NOT. maybe that's a common implementation pattern or something, but I agree with Ian that there's no reason to prevent servers from making them the same.
[07:54] jim conallen (IBM): current issues: status code and media types, but we (as a group) are not ready to comment on this in the meeting today
[07:54] Lonnie (Sodius): Here's what I implement. Notice that it is the media type that indicates we are to return the Compact. During our implementation, I didn't notice that properties differ depending on whether the resource or the compact was sought.
[07:54] Lonnie (Sodius): @GET @Path("{changeRequestId}") @Produces({OslcMediaType.APPLICATION_X_OSLC_COMPACT_XML}) public Compact getCompact(@PathParam("changeRequestId") final String changeRequestId)
[07:58] jim conallen (IBM): john: not right to use 200 to return a representation of a different uri
[08:00] jim conallen (IBM): the spec should say use 209, but if not available use a 3xx
[08:02] jim conallen (IBM): it is not uncommon to return other resources in a response (eg. inlining)
[08:04] jim conallen (IBM): steve: since spec will be around a while, we should have 209 in there to be ready for this
[08:07] John Arwe (IBM): what steve was saying earlier sounded reasonable, I think it will take a concrete example or 3 though to be sure we're all meaning the same thing
[08:10] jim conallen (IBM): Steve pointed out that Lonnie's example earlier would involve some changes to accomidate prefer header
[08:10] Lonnie (Sodius): We are learning and this is our first approach; we are amenable to implementing it different ways. I don't really "have a dog in the fight" yet for one way or the other.
[08:11] jim conallen (IBM): John/Steve: we need to draft examples,
[08:11] jim conallen (IBM): Steve accepted action item and immediately delegated to Sam
[08:12] jim conallen (IBM): Arnaud: we can finish discussion for today, follow up in mailing list.
Assign reviewer for Actions and Automation specs
[08:13] jim conallen (IBM): Arnaud: next item; two specs to review. we should assign 2 people to review.
[08:13] Martin Pain (IBM): Original review request to Core WG: http://open-services.net/pipermail/oslc-core_open-services.net/2014-April/001752.html
[08:14] Martin Pain (IBM): Primer for Actions spec: http://open-services.net/wiki/automation/OSLC-Automation-Primer/#OSLC-Actions
[08:14] Martin Pain (IBM): Automation 2.1 spec: http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/
[08:14] Lonnie (Sodius): I can't commit to be a formal reviewer while I need to read this. Sodius is attempting to get OSLC product ready for Innovate and that is consuming my time and the time of my team.
[08:14] John Arwe (IBM): Actions is intended to be a future contribution to Core; Automation 2.1 is the first visible context in which it will be used, and is a likely future contribution to the Automation TC
[08:15] Lonnie (Sodius): After June, for sure
[08:15] John Arwe (IBM): from martin's email: Our expectation has been to leave two weeks for the Core WG review.
[08:18] jim conallen (IBM): Ian and Nick, volunteered to review
[08:19] John Arwe (IBM): Everyone present bottlenecked on Innovate (first week of June)
[08:19] jim conallen (IBM): Ian can not look at until after Innovate - Arnaud: good enough to have names at this point
[08:19] Lonnie (Sodius): After Innovate, yes.
Any Other Business
[08:20] jim conallen (IBM): Steve: can we drop consumer/provider (from oauth) to client/server?
[08:21] jim conallen (IBM): John: in HTTP specs they use client/server and have very specific definitiojns
[08:22] John Arwe (IBM): as well as terms that solve the human/code ambiguity that martin raised
[08:22] Lonnie (Sodius): I _like_ consumer and provider and we use it through our code and design documentation and structure.
[08:22] Sam Padgett (IBM): +1 on client/server from me
[08:23] John Arwe (IBM): We also have the consumer/provider terms in our publications and code comments now, I'm just willing to make them change.
[08:24] jim conallen (IBM): Steve: as we consistently talk about these concepts we can start using client/server, have a note indicating that means the same as when we said consumer/provider
[08:24] John Arwe (IBM): Lonnie, do you believe that your existing usages would be compatible with HTTP's client/server terms?
[08:25] John Arwe (IBM): ...if not, what differences do you think exist?
[08:25] Arnaud J Le Hors (IBM): STRAWPOLL: Use client/server instead of consumer/provider moving forward (i.e., in OASIS specs)
[08:25] Steve Speicher (IBM): +1
[08:26] jim conallen (IBM): +1 - client/server
[08:26] Martin Pain (IBM): Strawpoll response: slightly against - would prefer consumer/provider
[08:26] John Arwe (IBM): +1 (with bridge to the older terms so readers have an easier transition)
[08:27] Martin Pain (IBM): -1
[08:27] Nick Crossley (IBM): 0
[08:27] John Arwe (IBM): Was it your intent to block, Martin?
[08:27] Martin Pain (IBM): no
[08:27] Martin Pain (IBM): -0.9
[08:27] ian green1: +1
[08:27] Steve Speicher (IBM): good we don't have to kill
Martin
[08:28] John Arwe (IBM): hah - read that as The Other Martin at first
[08:28] Steve Speicher (IBM): maybe it was
[08:28] jim conallen (IBM): LOL
[08:28] John Arwe (IBM): Freudian slip
[08:29] jim conallen (IBM): Steve has more business: LDP moving forward
[08:29] Lonnie (Sodius): poll response: ~0
[08:29] Lonnie (Sodius): thank you
[08:29] jim conallen (IBM): Arnaud: propose close call - thanks all
Adjourn
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]