> ISSUE-12: Arwe did some slight rewording in the two comment sites. Good
> ISSUE-17: Arwe reviewed second comment, attempted to untangle it > some (I had trouble resolving this/that/... references), thinks he > found a bug (below) as a result. Took a quick look at first > comment; once we settle on the bug (is it a bug or not) we might > want to propagate some subset of what I did on the 2nd comment; 1 is > already more concrete (so much less tangled), just a question of how > beautiful a sheen the nose cone has. > > Comment 1: http://open-services.net/wiki/automation/OSLC-Automation- > Specification-Version-2.1/#Creation-Factory-interaction-pattern > Comment 2: http://open-services.net/wiki/core/Exposing-arbitrary- > actions-on-RDF-resources/#Interaction-patterns Comment 2 is now more readable, and still matches my understanding. > A FB-200 means "I did it" > (past tense, otherwise it should be a 202). A AR-200 means "I > created the AR, now you [consumer] monitor it until state/verdict > say it's baked". I would expect AR factories to return a 201 Created response code. Appendex A states: http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#constructing-http-requests "201 (Created) to indicate that the request resulted in the creation of a new resource; the Location response header provides the URL of the newly created resource. The client is responsible for interrogating the resource’s state to determine whether or not the action has completed. One use of this in certain profiles is to use the OSLC Automation specification’s mechanisms to monitor its progress and success/failure." So the only issue, as I see it, is if providers respond with a 200 when it has created an Auto Request, which I would consider to be bad practice anyway (I haven't checked if the spec says what response code it should use, but I woudn't be suprised if it doesn't say). Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU "Oslc-Automation" <[email protected]> wrote on 12/03/2014 19:57:36: > From: John Arwe <[email protected]> > To: [email protected], > Date: 12/03/2014 19:58 > Subject: Re: [Oslc-Automation] Changes I have made to Actions specs > based on Actions issues list > Sent by: "Oslc-Automation" <[email protected]> > > ISSUE-12: Arwe did some slight rewording in the two comment sites. > Comment: http://open-services.net/wiki/core/Exposing-arbitrary- > actions-on-RDF-resources/#executing-actions > the parenthetical sentence is now a clause after the semicolon. > split the paragraph so the resource concerns are separate from the clients'. > > moved unrelated "resources can be hash/less or blank" higher up, > under Action Resources, where it was partially dup'd already. > > Cardinality: http://open-services.net/wiki/core/Exposing-arbitrary- > actions-on-RDF-resources/#Resource-Action > > Comment: http://open-services.net/wiki/core/Exposing-arbitrary- > actions-on-RDF-resources/#property-oslc-action > Merged the paragraph Martin had updated into the predicate desc > column, so it has a more natural home after it moves to Common Properties. > > > ISSUE-14: Arwe reviewed, seemed fine. > > > ISSUE-17: Arwe reviewed second comment, attempted to untangle it > some (I had trouble resolving this/that/... references), thinks he > found a bug (below) as a result. Took a quick look at first > comment; once we settle on the bug (is it a bug or not) we might > want to propagate some subset of what I did on the 2nd comment; 1 is > already more concrete (so much less tangled), just a question of how > beautiful a sheen the nose cone has. > > Comment 1: http://open-services.net/wiki/automation/OSLC-Automation- > Specification-Version-2.1/#Creation-Factory-interaction-pattern > Comment 2: http://open-services.net/wiki/core/Exposing-arbitrary- > actions-on-RDF-resources/#Interaction-patterns > > > > Bug(?) unearthed on -17 review: the AutoRequest IP[1] says that it > extends the fixed-body IP. So as I was reading -17 comment 2, > trying to Really Clarify why this was a problem for clients, I came > to a contradiction: if AR really is a (valid) extension of FB, then > a client *should* be able to use either (treat AR as if it were FB). > Yet I know in practice that fails - not on the send side, but on the > "how to interpret the response" side. A FB-200 means "I did it" > (past tense, otherwise it should be a 202). A AR-200 means "I > created the AR, now you [consumer] monitor it until state/verdict > say it's baked". I think Martin you thought about the inheritance > of IPs purely from the send side, without considering "what does 200 > mean"; at least that's my best attempt to make sense of the > currently drafted content. I think the interaction pattern > (execution sections, probably) need to include how the response is > interpreted (ptr to HTTP for most, Automation for others). I > suspect that drives a change to the syntax - if AR is not an > extension of FB, then the recognition rule has to change. > > It should still be *possible* to use an AR as the payload of a FB > IP, but in that case the provider can only do that if it > *guarantees* that it uses the FB IP (meaning it Must Not return 2xx > if the verdict/state is anything other than success). I think > Automation 2.0 would still allow that; it's kind of a corner case > since anything other than 201 or "the create AR itself failed" is > off the mainline path. An Automation 2.0 provider would simply > expose AR-only bindings, or (if it meets the tighter criteria) it > could expose the same actions via equivalent FB bindings (whose body > just happens to be an AR, but that's transparent to the client). > > > > [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#pattern-autoreq > > > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
