A few items below... Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net
Martin P Pain <[email protected]> wrote on 01/30/2014 05:57:17 AM: > From: Martin P Pain <[email protected]> > To: Steve K Speicher/Raleigh/IBM@IBMUS > Cc: [email protected], "Oslc-Automation" <oslc-automation- > [email protected]>, [email protected] > 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: [email protected] > 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 <[email protected]> > To: [email protected], > Cc: [email protected] > Date: 30/01/2014 03:17 > Subject: [Oslc-Automation] Some comments on Actions spec (most from > CM perspective) > Sent by: "Oslc-Automation" <[email protected]> > > > > 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 > [email protected] > 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
