Attached is my proposed changes to the Action resources 2.0 spec, to split out the definition of "interaction patterns" from "implementation profiles".
I think this simplifies things, so that consumers that wish to implement understanding of everything can implement all interaction patterns without being concerned with implementation profiles at all (e.g. the restrictions on the profile use by CM about the requestURI must be the request of the action), and it simplifies the idea of interaction patterns extending other interaction patterns. It allowed me to address the question of "how do you identify the interaction pattern in use" without having to identify the implementation profile in use, which would be harder as they may (in the CM case) contain other restrictions. My changes are done using "track changes" in the attached doc, and consist of: * An introduction to actions for people who don't want to dive straight into the spec. (The first two paragraphs I've already put in the wiki page, as I believe they are not contentious). * A description of the use of interaction patterns, and the definition of all the ones that I'm aware that we've talked about so far. * Linking the implementation profiles to the interaction patterns. Note that I have quite heavily reintroduced the term "Action implementations", meaning the ways that a request can be formed to execute an Action. The relationship with interaction patterns is: each Action implementation "uses" (or "identifies") one or more interaction patterns. Usually one, but it has to allow the "many" case for when interaction patterns extend each other, e.g. the Automation Request pattern is a specialisation/extension of the "HTTP Request" pattern. However the dual use of the word "implementation" (in both "Action implementations" and "implementation profiles") may cause confusion, so we may want to rename Action Implementations to be something else, but they are not always "requests", e.g. when they use the "Dialog" interaction pattern. You may wan to skip most of the definitions of the interaction patterns themselves, as my changes are quite long. Perhaps just look at "HTTP Request" as the most basic one, and "Resource shapes" or "Automation Requests" as an example one an extension of an interaction pattern, but don't get hung up on the details just yet. Kind regards, 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
2013-12-11 OSLC Actions interaction patterns.odt
Description: Binary data
