[oslc-cm] [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-cm_open-services.net/attachments/20140130/1aa50f9b/attachment-0003.html>
More information about the Oslc-Cm
mailing list