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. 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). 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. 3. oslc:request is now called oslc:binding. 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: 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 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
