[Oslc-Automation] Some comments on Actions spec (most from CM perspective)

Steve K Speicher sspeiche at us.ibm.com
Thu Jan 30 08:31:27 EST 2014


A few items below...

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net

Martin P Pain <martinpain at uk.ibm.com> wrote on 01/30/2014 05:57:17 AM:

> From: Martin P Pain <martinpain at uk.ibm.com>
> To: Steve K Speicher/Raleigh/IBM at IBMUS
> Cc: oslc-automation at open-services.net, "Oslc-Automation" 
<oslc-automation-
> bounces at open-services.net>, oslc-cm at open-services.net
> Date: 01/30/2014 05:57 AM
> Subject: Re: [Oslc-Automation] Some comments on Actions spec (most from 
CM 
> perspective)
> 
> What you call the "domain specific types" were an attempt to find things 

> from the domain-driven requirements that might be useful across domains 
or 
> in the general case. However, as the oslc_cm:targetState property has to 
be 
> OSLC CM-specific (as it implicitly refers to the oslc_cm:state property) 
I 
> guess there's no use in including the oslc:StateTransitionAction type in 

> core, if we have it at all. 
> 
> As for the usefulness of having that type at all, the intention was 
having a
> single place to look to determine the type of actions - the rdf:type 
values.
> But if you've got another way of identifying them (the 
oslc_cm:targetState 
> property) then I guess that's enough. 
> 

I guess one could say there are many types of resources, not just CM, that 
have 'state' and there could be a case for oslc:state + oslc:targetState 
(noticed I picked the core namespace).  Though part of me says "it is just 
a namespace" and if defined properly, people could just reuse from CM.  I 
haven't heard enough people asking for this from various domains but in 
practice I have seen many tools support something like this.

> A couple of points on your examples: 
> 1. The resource shape interaction pattern [4] says the name of the 
predicate
> pointing to the resource shape is oslc:requestBodyParameters (although 
in 
> recent discussion I've suggested using http:body, as it is being used to 

> construct the body). 
Right, I just copied an old CM example and didn't change it.

> 2. The profile you mentioned invokes the "Standard restrictions on 
http:Request
> resources for simple specification profiles" from appendix A [5], which 
> includes "the providers MUST... provide at least one binding that... 
> specifies "1.1" as the value of the http:httpVersion property." (This is 
to 
> allow us to specify HTTP 2 [6] in the future, in a way that lets older, 
pre-
> HTTP 2 consumers know that HTTP 1.1 is not supported). Your example is 
> missing this property. 

Is POST in HTTP 2.0 really going to be incompatible? I assume this 
property is multi-valued, if my provider can handle 1.1 or 2.0.

> 3. oslc:request is now called oslc:binding. 

I just used the examples from Appendix B as a guideline, that is where I 
picked up oslc:request [1].

[1] - 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Appendix-B.3A-Examples


> 
> Other than those minor points, that example looks exactly what I've got 
in mind. 
> 
> 
> [4] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-
> resources/#pattern-resource-shape 
> [5] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-
> resources/#Standard-restrictions-on-http.3ARequest-resources-for-simple-
> specification-profiles 
> [6] http://tools.ietf.org/html/draft-ietf-httpbis-http2-00
> 
> 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:        Steve K Speicher <sspeiche at us.ibm.com> 
> To:        oslc-automation at open-services.net, 
> Cc:        oslc-cm at open-services.net 
> Date:        30/01/2014 03:17 
> Subject:        [Oslc-Automation] Some comments on Actions spec (most 
from 
> CM        perspective) 
> Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net> 
> 
> 
> 
> I took the action to do a quick review for CM needs and look how it may 
be 
> spec'd for CM [1] 
> 
> Comment on section [2] 
> I'm not sure why the domain specific types are here.  Seems like 
something 
> that would be in CM spec.  In fact, we probably wouldn't define a 
> oslc:StateTransitionAction but instead just call it oslc:Action.  Seems 
like
> the parent class is extraneous.  Clients will be looking for 
> oslc_cm:targetState to determine which action to pick. 
> What value is there in having this separate type? 
> 
> CM would simply use profile "POST RDF described by OSLC shapes" [3] 
> 
> Figured I will just sketch out how it will be used below, which seems to 
be 
> a slight modification of what we already had spec'd. 
> 
> @prefix oslc: <http://open-services.net/ns/core#>.
> @prefix oslc_cm: <http://open-services.net/ns/cm#>.
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
> @prefix dc: <http://purl.org/dc/terms/>.
> <http://example.com/bugs/2314>
>  a oslc_cm:ChangeRequest;
>  oslc_cm:state <http://open-services.net/ns/cm#Open-state>;
>  dc:identifier "2314";
>  dc:title "Provide import";
>  oslc:action <http://example.com/bugs/2314?_action=resolve>,
>              <http://example.com/bugs/2314?_action=start>.
> 
> <http://example.com/bugs/2314?_action=resolve>
>  a oslc:Action;
>  dc:description "Indicates work is complete on the change request.";
>  dc:identifier "23";
>  dc:title "Resolve"; 
>   oslc:request <#req1>;
>  oslc_cm:targetState <http://open-services.net/ns/cm#Resolved-state>.
> 
> <http://example.com/bugs/2314?_action=start> 
>  a oslc:Action;
>  dc:description "Indicates work is beginning on the change request.";
>  dc:identifier "24";
>  dc:title "Start Working";
>  oslc:request <#req2>;
>  oslc_cm:targetState <http://open-services.net/ns/cm#In-progress-state>. 

> 
> <#req1> a http:Request; 
>   http:requestURI <>; 
>   http:mthd http-methods:POST 
>   oslc:resourceShape <http://example.com/bugs/action/resolve/shape>.
> 
> <#req2> a http:Request; 
>   http:requestURI <>; 
>   http:mthd http-methods:POST 
>   oslc:resourceShape <http://example.com/bugs/action/start/shape>.
> 
> 
> [1] - 
http://open-services.net/wiki/automation/AutomationMeetings20140123/#Minutes 

> [2] - 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-
> resources/#Resources.3A-Action-types 
> [3] - 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-
> resources/#profile_POST_resource_shape 
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> 
http://open-services.net
> _______________________________________________
> 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/20140130/1aa50f9b/attachment-0003.html>


More information about the Oslc-Automation mailing list