[Oslc-Automation] [oslc-core] review of actions 2.0 - Part II (1-3) : Typos, clarifications

[John Arwe]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140806/6ea94dad/attachment-0003.html>