The changes I've made are: 1. I renamed oslc:desiredResult to oslc:finalStatusLocation, as it identifies a location, not a result itself, and it does not necessarily tell you the desired result, just whether or not that was achieved, and also to emphasise the idea that it is the final status of the action, not an intermediate one. (So even when used with the value http:StatusCode it's saying "the only HTTP status is the final status".) [1] [2] and also in the Automation 2.1 spec: [3] [4]
Most of the other changes flow from this: 2. I introduced the term "final status" in the text of the "interaction patterns" section. [1] 3. I made it clear that the values we provide are to be used as URIs (i.e. not as rdf:types on a resource which is the object of oslc:finalStatusLocation) - this involved both additional text before the list of values we provide [1], plus a change to the 'resource shape' table [2]. 4. I allowed multiple values for oslc:finalStatusLocation ([1], [2]), in case the final status is reflected in more than one place (to allow future interaction patterns to aid backwards-compatibility/interoperability by using one of the values we define here (e.g. http:StatusCode) alongside a future one that may give more detail (along the lines of oslc-automatino:AutomationResult). This also required an update in each of the recognition rules to say "at least one oslc:finalStatusLocation value..." rather than "the oslc:finalStatusLocation value..". 5. I included a note as to why these aren't implied by the interaction patterns - why they're in the RDF & recognition rule, using the example of an AutomationRequest that is always synchronous and (in the case of a specific provider) also reports the status of the execution in the HTTP status code. These are all along the same lines as what was there before, so I do not see any problems with including these changes. I know John is not against renaming this predicate, and I have dicussed the new name with Umberto. If there are any problems, please let me know. I've updated the examples & diagrams, and now I intend to send a request to the core WG to review the spec. [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Interaction-patterns [2] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Request-Properties [3] http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#pattern-autoreq-creation-factory [4] http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Template-Dialog-interaction-pattern 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 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
