[Oslc-Automation] first cut at split of auto request from fixed body is live
Martin P Pain
martinpain at uk.ibm.com
Mon Mar 24 10:47:32 EDT 2014
> I revised the text in the direction Martin suggested
Looks better.
What about 202? Would you say that's an exception to the "interpret that
to mean that the action ran successfully", as HTTP defines to to mean
accepted for later processing? Do you intend "Single-message interaction
pattern definitions SHOULD avoid other interpretations." to imply that if
pointing to an implementation that might return 202, then the action is of
the type "queue X for processing" rather than "process X"?
Why the bold text? The emphasis doesn't appear to add much.
> Q1: are we going to switch to parameter instance or not? I
> drafted everything using the words as they are now, i.e.
> ContentFromRepresentation.
My memory is that the consensus was favourable to the change. That is, yes
I believe we are going to change.
> 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.
If we were staying with ContentFromRepresentation I'd say yes, but if we
change to parameter instance I'm not sure it buys us anything.
> Q3: are we going to change the Automation Request pattern's
> recognition rule (more generally, all the red or red-bracketed
> content recently drafted)?
I votes yes, going to the red text (where ContentFromRepresentation is
removed).
> 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.
Immediate means "queued, but immediately eligible for execution", whereas
ActionDialog implies "synchronous" or, perhaps more accurately,
"single-'message' interaction pattern". So we can't reuse Immediate,
unless there's something else to distinguish these two cases.
I think I originally drafted it as a subtype, but then changed it to
usage. I can't remember exactly why.
> Q5: how are we going to use the ODT content going forward, and who's
> going to do any work required?
I was intending to update that and work it in to an appendix or examples
or scenarios page. I won't be able to do this before next week at the
earliest.
> 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.
We had discussed making the CF pattern AutoRequest-specific. If we do
that, we can then follow the same semantics as the AR pattern.
However, I like the idea of explicitly stating whether it's a
single-message flow, or a multi-message-immediately-eligible, or a
multi-message-deferred-execution. (Probably via two prodicates, one can
set SingleMessage or MultiMessage [where the former could replace
ActionDialog above], and the other - in the case of Automation and
MultiMessage - can specify Immediately
[immediately-eligible-for-execution] or Deferred [not eligible for
execution] - if this second one is ever appropriate.)
> 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.
I'll wait until the discussion on Q6 has progressed.
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
24/03/2014 13:54:36:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 24/03/2014 13:55
> Subject: Re: [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>
>
> 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: [image removed] and within IBM on: [image removed]
>
> [image removed]
>
>
>
>
>
> 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
> _______________________________________________
> 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/9a60a176/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/9a60a176/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/9a60a176/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/9a60a176/attachment.gif>
More information about the Oslc-Automation
mailing list