[Oslc-Automation] Some comments on Actions spec (most from CM perspective)
Martin P Pain
martinpain at uk.ibm.com
Thu Jan 30 13:03:16 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-automation_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-automation_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-automation_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-automation_open-services.net/attachments/20140130/8e71137f/attachment.gif>
More information about the Oslc-Automation
mailing list