[Oslc-Automation] Changes I have made to Actions specs based on Actions issues list
Martin P Pain
martinpain at uk.ibm.com
Thu Mar 13 06:59:00 EDT 2014
> 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: martinpain at uk.ibm.com
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" <oslc-automation-bounces at open-services.net> wrote on
12/03/2014 19:57:36:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> 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" <oslc-automation-bounces at open-services.net>
>
> 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
> Oslc-Automation at open-services.net
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/77a2ef48/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/77a2ef48/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/77a2ef48/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/77a2ef48/attachment.gif>
More information about the Oslc-Automation
mailing list