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 <martinp...@uk.ibm.com>
To: John Arwe/Poughkeepsie/IBM@IBMUS,
Cc: oslc-automation@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: martinp...@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 <johna...@us.ibm.com>
To: oslc-automation@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-boun...@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@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
