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

Martin P Pain martinpain at uk.ibm.com
Thu Jan 30 13:03:43 EST 2014 

> 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. 

My interpretation is that it could be multi-valued - we ought to add this 
to the interpretation in the appendix. Good thought.


> 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).
See other emails:
http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000641.html
http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000644.html

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 
30/01/2014 13:31:27:

> 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 13:31
> Subject: Re: [Oslc-Automation] Some comments on Actions spec (most 
> from CM perspective)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> 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 
thepredicate
> > 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] 

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-cm_open-services.net/attachments/20140130/8e71137f/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-cm_open-services.net/attachments/20140130/8e71137f/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-cm_open-services.net/attachments/20140130/8e71137f/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-cm_open-services.net/attachments/20140130/8e71137f/attachment.gif>

More information about the Oslc-Cm mailing list