[Oslc-Automation] first cut at split of auto request from fixed body is live

John Arwe johnarwe at us.ibm.com
Mon Mar 24 09:54:36 EDT 2014


I revised the text in the direction Martin suggested, although not using 
his exact words.  I had similar "not all HTTP" thoughts myself when 
drafting, but since we're in OSLC space I concluded we can assume HTTP as 
the protocol; nevertheless I insisted a few angels learn the rhumba on the 
pinhead of IP definition.  What's there now I think addresses that thought 
without becoming a distraction.

I also added (trivial) examples of ALL the interaction patterns in Core, 
and linked them from each IP's defining section in Actions.

In the course of all this, a few questions arose.  We might be able to 
close them in email, but if not I'd like to do so on Thu.
Q1:  are we going to switch to parameter instance or not?   I drafted 
everything using the words as they are now, i.e. 
ContentFromRepresentation. 
Q2:  should we define ContentFromRepresentation (or its successor, if one 
arises) as a subclass of cnt:Content ?  The HTTP in RDF vocabulary asserts 
that body's range is cnt:Content.
Q3: are we going to change the Automation Request pattern's recognition 
rule (more generally, all the red or red-bracketed content recently 
drafted)?
Q4: the immediate action dialog binding looks a bit odd, insofar as it has 
type=Dialog and usage=ActionDialog (which looks a bit like a subtype), vs 
the other dialogs' usage values of Immediate and Deferred.  I don't see 
anything (at a quick glance) stopping us from either re-using the 
Immediate usage vocabulary term that Automation 2.1 defines, or changing 
ActionDialog to be a type (although doing so Might conflict with Deferred 
or Automation 2.0 behavior, I'd have to check), or changing ActionDialog's 
name to be a further Hamming distance way from the Action and Dialog 
types.  I can live with "looks a little odd" myself, if everyone else is 
content to stop fussing with it.
Q5: how are we going to use the ODT content going forward, and who's going 
to do any work required?
Q6: Apropos the recent discussion about single vs multi-message patterns, 
I'm not sure what the expectation is on Creation Factory in Automation 
2.1. ... if I get a 200 or 201 there, as a client am I *required* to look 
anywhere else for the "goal" status or is the HTTP message status code 
always identical to the goal status?  2.1 points to Core, and Core allows 
either mode by my reading.  I'd be tempted to say that CF's used in a 
binding MUST declare their "style" via a usage value of Immediate or 
Deferred.  Any other values, including none, could not be recognized as 
using the CF IP.
Q7:  Auto 2.1's immediate bindings section is silent on whether or not CF 
is valid; this answer likely flows from Q6's answer.

Core Actions' outstanding work is down to resource shapes (and I'm not 
touching those until the questions above are close), fleshing out any 
examples that people feel are too trivial (others feel free to help), and 
whatever comments come in.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Martin P Pain <martinpain at uk.ibm.com>
To:     John Arwe/Poughkeepsie/IBM at IBMUS, 
Cc:     oslc-automation at open-services.net
Date:   03/24/2014 06:50 AM
Subject:        Re: [Oslc-Automation] first cut at split of auto request 
from fixed      body is live



"Interaction patterns" section changes: 

"using a binding to construct one or more HTTP messages " - currently 
they're all HTTP messages (although the deleagted UI dialog is an indirect 
HTTP message by creating an iframe), but I could see non-HTTP bindings 
being created in future, e.g. to send an MQTT message. On the one hand all 
the ones we have at the moment are HTTP, so we may not need to cater for 
this future possibility in our wording, but on the other hand we might not 
want to restrict the bindings that other specs can define. 

I would also not jump straight into the single vs multiple flow problem, 
perhaps something like this: 

Consumers invoke actions to achieve a certain goal (desired result) using 
a binding, and that binding's interaction pattern, to know the steps to 
take to invoke that action. Each action can have one or more bindings, as 
alternatives to each other,[1], and each binding can use one or more 
interaction patterns, also as alternatives to each other[2]. Each binding 
gives the specific details that are needed to execute any of its 
interaction patterns for this particular action, for example the HTTP 
message to construct, if using any of the HTTP-based interaction patterns. 


Most of the interaction patterns involve the consumer constructing one or 
more HTTP messages. Some interaction patterns always consist of a single 
message, but others permit or require multiple messages to achieve the 
same goal. This distinction becomes critical when a consumer is trying to 
determine whether or not its goal has been achieved, based on message 
responses. 
When using interaction patterns that always consist of a single message 
flow, consumers will expect the HTTP status code to equate to the success 
or failure of the goal (executing the action): if a success status code 
(2xx class) is returned (other than "202 accepted"), consumers will 
interpret that to mean that the action ran successfully. Single-message 
interaction pattern definitions SHOULD avoid other interpretations. 
When using interaction patterns that sometimes or always consist of 
multiple message flows, in general consumers cannot expect “the” HTTP 
status code to equate to the success or failure of the goal (executing the 
action), because the issue of which message’s status code to use arises. 
Multi-message interaction patterns MUST define how a consumer 
unambiguously determines the status of its goal from the messages. 
        [1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#executing-actions

       [2] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#recognizing-patterns




"Pattern: Automation Request" section changes: 

If we're not inheriting from HTTP fixed body any more, what about using a 
Creation Factory resource, rather than an http:Request? 
However: (1) we currently have no way of specifying the AutoRequest to use 
as the template 
(2) Similar to the problem with extending HTTP requests, we would need to 
make sure this could be distinguished from "single-request creation" 
actions, for exactly the same reasonas as mentioned in your previous 
change. 
It's probably simplest to leave it as an http:Request message, as then we 
have the fact that the http:body resource's rdf:type is AutomationRequest 
to distinguish it from any other for of HTTP interaction pattern.

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 



From:        John Arwe <johnarwe at us.ibm.com> 
To:        oslc-automation at open-services.net, 
Date:        21/03/2014 21:17 
Subject:        [Oslc-Automation] first cut at split of auto request from 
fixed        body is live 
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net> 



[1]  has the prose on general IP-level mixing rules 
[2]  has updated Auto Req recognition rule + proposal to change it 
both red for now so it's easy to review just the changes 

I have to search for other side effects (I know there's still a lingering 
stmt that an AR binding *could* be recognized as FB IP, but that's the 
point of the proposal at [2]). 


[1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns 

[2] 
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/20140324/d3d0f08f/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/20140324/d3d0f08f/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/20140324/d3d0f08f/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/20140324/d3d0f08f/attachment.gif>


More information about the Oslc-Automation mailing list