[Oslc-Automation] The words "potentially consumable" (was: review of actions 2.0 - Part II (1-3) : Typos, clarifications)

Thu Aug 7 05:45:48 EDT 2014

(I've made sure that my two responses to the review have gone to core, 
automation and Ian directly. I have suggested to him to make sure he is 
subscribed to this list.)

Re "potentially consumable" (points numbered according to the numbers in 
John's email):

1 - compatibility of interaction patterns:
I think the later sentence "If at least one of the bindings is compatible 
with this consumer, then the action is compatible with this consumer." 
covers the issue of compatibility, so I don't think we need the words 
"potentially consumable" in the earlier point to cover that case.

2 - filtering actions to display:
I think the later sentence "Do whatever the client is coded to do" covers 
the issue of the the consumer deciding whether to display them or not.

(Note that we have another typo: we ought to substitute "client" with 
"consumer" in that sentence.)

3 - user not selecting them:
As you have said, they are already "consumed".

4 - others:
"Do whatever the client is coded to do" probably covers anything - the 
client can do anything with them.

So I suggest the words "potentially consumable" are unneeded. Unless, John
, you suggest that your cases (or other unknowns may still need them) then 
I propose that we remove them.

Ian, does this cover your concerns about talking about "consuming" 
actions, or does this word occur elsewhere where it is undefined what it 
means to "consume" an action? All the other occurrences seem to talk about 
"consumers", which is defined, so I expect removing this one phrase will 
address your comment. Is this true?

(However, the definition of consumer does talk say they use oslc:Actions 
"to execute that action using its action bindings" - and I've already said 
there's potentially a problem with the word "execute".)

Potential changes:
A: Remove "potentially consumable"
B: We could expand on what "Do whatever the client is coded to do" means, 
perhaps by adding "For example, present them to a user to select which 
one(s) to execute."
C: When talking about what the client does when it wants an action 
executed, we could change the word "execute" to "trigger execution" or 
"request execution". (When not talking about the client-side specifically, 
but the entire situation, then the word "execute" alone should be fine). 
Does anyone think this is worth doing?

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical 
committee 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:   06/08/2014 16:48
Subject:        Re: [Oslc-Automation] [oslc-core] review of actions 2.0 - 
Part    II      (1-3) : Typos, clarifications
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>

Is Ian subscribed to Automation, so he's seeing this thread? 
> 2. Section "Domain-specific consumers": 
> 
> 2.1 Do actions get "consumed"? 
> The problem with the word "executed" is that there are two parts to 
> the execution. The consumer/client sends an HTTP request (or 
> similar) and the provider/server does something as a result. The 
> "execution" could either refer to both sides of that, or just to the
> provider/server side. 
> If you're referring to the word "consumed" in the phrase "Find 
> potentially consumable, currently available ", I can't remember what
> we meant by "potentially consumable" other than what is described in
> the steps further down (regarding checking compatibility of 
> interaction patterns). John, can you remember? 

"Consumer" generally is used (in OSLC) for the role that HTTP calls 
"client"; I've been corrected on that by others (as I got used to writing 
'client' in LDP, that crept into Actions, and I had to scrub Actions 
afterward). 
The "potentially consumable" weasel words cover a bunch of possible cases 
that boil down to: this is the list of all possible actions, and the 
client (of the Actions resources) may filter that list before presenting 
anything to a user (human or machine) 

1: compatibility of interaction patterns 
1a: we already have the "Automation for everything" and "WTH is Automation 
and why do I care?" camps, and they both want Actions 
1b: HTTP 2 is going to start rolling out "soon", if mnot has his way, 
which might introduce more fragmentation 
1c: we have existing products looking to exploit Actions on the same 
resource type (see 2) and instance (collection level) that differ in terms 
of their 1a camp membership. 

2: A generic UI (like a dashboard widget) might filter the list of 
available actions prior to display (RTC might limit its display to 
CCM-relevant ones).  CSI has the notion of collections of faceted data 
about a resource (usually, of the "real world" sort), with a set of 
actions per facet, but to a user the collection is "the thing" (computer 
system, application, ...). 

3: A UI might *display* all 'n' actions (that pass any filters like 1-2 
above), and the user selects 1 (or 0) of them to actually invoke/execute. 
The UI code has still done *something* with them (consumed), even if it 
hasn't executed any of them in any sense (the 0-selected case). 

4: maybe others I'm forgetting today 

Best Regards, John

Voice US 845-435-9470  BluePages 
Cloud and Smarter Infrastructure OSLC Lead 
_______________________________________________
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/20140807/23822985/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/20140807/23822985/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/20140807/23822985/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/20140807/23822985/attachment.gif>