[Oslc-Automation] Actions 2.0 finished. Re: Final proposals for OSLC Actions 2.0

Martin P Pain martinpain at uk.ibm.com
Mon Feb 9 11:01:03 EST 2015


These changes from below have now (finally) been made to the Actions 2.0 
spec. Unless there are any prompt objections, I will mail the 
open-services.net Core WG to mark Actions 2.0 and Automation 2.1 (see 
previous email) as in finalization, and contribute them to OASIS.



Something of an overview of the changes are here, but see the email below 
for more detail:

rdf:value is now AnyResource, but I haven't changed recognition pattern.


Each interaction pattern and profile now has a table listing its name, an 
identifier for it, and which patterns it contains or which profiles 
contain it. Profiles also list where they are used, which for one of them 
is a link to CM which never decided whether to use it or not.


Ian.II.7.4:
Resource: results
This resource is returned by the delegated UI dialog for immediate 
execution to indicate the status (“verdict”) of the execution of the 
action.


Requirements on RDF/XML removed


Ian.II.8.1:

"terminology" section:

**[Specification profile](#Specification-profiles)** - a named, coherent 
subset of a specification, often used in a specific domain, like [Change 
Management](/wiki/change-management) or [Automation](/wiki/automation). An 
actions _specification profile_ includes one or more _interaction 
patterns_ for which each _Action_ resource governed by that _profile_ must 
provide an _Action binding_. The additional constraints simplify the range 
of code clients are required to implement, making it cheaper and easier to 
adopt. This is a specification-only concept, not a runtime concept.

Profiles overview:

An _specification profile_ is a coherent subset of this specification. A 
_specification profile_ includes one or more _interaction patterns_ for 
which each _Action_ governed by that _profile_ must provide an _Action 
binding_. The additional constraints simplify the range of code clients 
are required to implement, making it cheaper and easier to adopt. This is 
a specification-only concept, not a runtime concept.



"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
09/10/2014 16:56:42:

> From: Martin P Pain/UK/IBM at IBMGB
> To: oslc-automation at open-services.net
> Date: 09/10/2014 16:57
> Subject: [Oslc-Automation] Final proposals for OSLC Actions 2.0 - please 
+1
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> ---------- 
> These are the final proposals to go into OSLC Actions 2.0. Please 
> read them and +1 if you are fine for them to be resolved as stated. 
> If there are no objections in a week, they will be considered 
> resolved by the WG. 
> ---------- 
> 
> Ian.II.7.5: literal values for ParameterInstance rdf:value property 
> in fixed body pattern. 
> Proposal: "Change the resource shape (resource table) for Actions' 
> reuse of ParameterInstance [1] to exclude literals, and make the 
> HTTP Request with Fixed Body interaction pattern explicitly require 
> a resource as the object of the rdf:value property. Also remove any 
> other text referring to literal values in this context." 
> (Resource shapes/tables set expectations, not compliance. 
> Implementations are still free to use literal values, but the spec 
> does not state how a consumer should interpret that.) 
> 
> Ian.II.8.2: Identifier for profiles; Ian.II.9.4: Identifier for 
> “standard restrictions” 
> Proposal: Add identifiers (listed below) for each interaction 
> pattern, identifying them in the spec as in the image at [2], except
> that: they are never to be used as link text (to avoid the 
> appearance of being parts of a URI), they should always be rendered 
> enclosed in quotes (to help reinforce that they are strings not 
> URIs). The "contained in profiles" and "used by" lists should either
> link to the other spec sections by name (not identifier) or in the 
> format: name ("identifier"). 
> Pattern: HTTP request with empty body ("pattern-http-empty-body") 
> Pattern: HTTP request with Resource Shape to describe the request 
> body ("pattern-http-resource-shape") 
> Pattern: HTTP request with fixed body ("pattern-http-fixed-body") 
> Pattern: Automation Request ("pattern-automation-request") 
> Pattern: Delegated UI dialog for immediate execution 
("pattern-action-dialog")
> Pattern: Delegated UI dialog for later execution ("pattern-
> delegated-execution-dialog") 
> Pattern: Automation Creation Factory 
("pattern-automation-creation-factory") 
> Profile: POST RDF described by a OSLC Resource Shape to the Action 
> resource ("profile-action-shape-post") 
> Profile: Create an Automation Request ("profile-automation-request") 
> 
> Ian.II.7.4: oslc:label & “action dialog”. 
> Proposal: "Add a link to the immediate execution action dialog 
> interaction pattern [3] in the introductory paragraph above the 
> resource shape for the "results" construct [4]". 
> 
> 2014-September/000838: Remove requirements on RDF/XML. 
> Proposal: Remove the sentence "Providers MUST support RDF/XML (i.e.,
> application/rdf+xml) representations of these resources. Providers 
> MAY provide representations beyond those necessary to conform to 
> this specification, using standard HTTP content negotiation. If the 
> client does not indicate a preference, application/rdf+xml MUST be 
> returned." and the two links to RDF/XML in the "references" section. 
> 
> ---------- 
> These proposals have been public for a number of weeks with no 
> objections, so are hereby considered resolved as proposed: 
> ---------- 
> 
> 2014-September/000834: Location of definition of "futureActions" 
> predicate and link from concrete actions to the future action they 
> correspond to. 
> Proposal: "Change namespace for new futureActions and executes 
> predicates to be core, leave all other spec locations & text as-is." [5] 

> 
> Ian.II.8.1: Complying with multiple profiles simultaneously. 
> Proposal: "In the Specification profile definitions section we 
> change the language from “Action bindings” (plural) to singular." 
> 
> 
> 
> 
> [1] 
http://open-services.net/wiki/core/Actions-2.0/#Resource_ParameterInstance
> [2] 
http://open-services.net/wiki/automation/622c751da3c971bab5d93ad0790ef8c0
> [3] http://open-services.net/wiki/core/Actions-2.0/#pattern-immed-dialog 

> [4] http://open-services.net/wiki/core/Actions-2.0/#Resource.3A-results 
> [5] http://open-services.net/pipermail/oslc-automation_open-
> services.net/2014-September/000845.html
> 
> 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/20150209/92c2fcbd/attachment-0003.html>


More information about the Oslc-Automation mailing list