History   View   Links to this page 2015 February 9 | 02:28 am

This page is to track issues with the Action resources 2.0 spec (Exposing arbitrary actions on RDF resources).

This page is currently managed by the OSLC Automation WG, while the Actions spec is being prepared for review by the OSLC Core (2.0 maintenance) WG or the OASIS OSLC Core TC.

  • OPEN - still in discussion
  • RESOLVED - resolution agreed, spec changes still required
  • RESOLVED - no further spec changes required.

Issues during draft development

  1. RESOLVED - Name of “Action implementation”. Options: “Request [resource]” (not suitable for dialogs), “Action implementation”, “instruction”, “option”.
    • 19 Dec 2013 - On Automation WG call, agreed use of term “Action binding”.
  2. RESOLVED - Name of parameters
    • oslc:request doesn’t seem to make sense for dialogs. We could go with something like oslc:implementation or oslc:instruction, or leave it to be defined by each top-level interaction pattern.
    • 20 Dec 2013 - I will shortly update the spec to use “oslc:binding” to match the resolution of issue #1
  3. RESOLVED - Literal request bodies (or other extensions to the values of http:body) might conflict with the “serialize the RDF” approach. Perhaps we should define an intermediate resource (of a new type, e.g. oslc:RdfBody) that identifies this as a “serialized RDF” body. I’d be interested in seeing how literal bodies might be represented to see if we can reuse something here. This might create a new interaction pattern, which would be the one that the AutoRequest pattern extends.
    • The idea described by issue 11 may well solve this problem.
    • 26 Feb 2014 Was resolved recently by introduction of oslc:ContentFromRepresentation
  4. RESOLVED - Split “HTTP request” pattern up? Perhaps one “abstract” parent pattern that does not specify how to construct the body with these child patterns: zero-body, RDF-body (parent of automation-request), resource-shape. Make sure that we’re explicit that action implementations can match more than one of these (e.g. a implementation using the automation-request pattern can also allow a nil-body).
  5. RESOLVED - Why is it important to restrict AutoRequest interaction pattern providers wrt CreationFactory semantics and putting the context in the Plan URI? I’m just not seeing what it prevents that’s bad at this point; I’m not ready to assert it’s unnecessary (yet).
    • The intention was to allow the consumer to go and find other ways to construct the request (e.g. finding a template dialog or creation dialog from the service provider). Now we’ve got a way to link to those dialogs from the action sits less important, but might still be useful for the cases where the providers just haven’t thought to include the dialogs in the actions.
    • If we remove these constraints I believe we need to remove the paragraph stating that consumers can find other ways to construct the Request.
    • 7 Jan 2014 - Putting context in Plan URI now removed. CreationFactory one still remains for now, I believe.
    • 26 Feb 2014 - Agreed with Arwe that this is no longer a problem.
  6. RESOLVED - Move definition of “pre-fill” (or otherwise what is done when an “execute later” pattern comes to execute an implementation later and has data to insert into it) into interaction patterns (i.e. into the ones that would be used at the “later time”).
    • 7 Jan 2014 - Resolved, but may be un-done when “execute later” moves in to Automation spec.
  7. RESOLVED - Simplify CM profile by moving constraints into pattern?
    • Simplified the profile, but still need to sort out the patterns (under issue #4)
  8. RESOLVED - What should be the level or restriction on domain specs re: identifying a profile? MUST they identify one, or SHOULD they identify one? What would be the problem if they don’t. Can we be more specific than just “interoperability will be reduced”?
  9. RESOLVED - Define initial action types.
    • Some are CM-specific (e.g. equivalents of the predicates already on their pages).
    • Some may be generic, e.g. oslc:CreaionAction, oslc:UpdateAction* (superclass of oslc:StateTransitionAction, if needed), oslc:DeletionAction.
    • Some may be specific to Automation: oslc_auto:StartAction, oslc_auto:StopAction, oslc_auto:PauseAction, oslc_auto:RestartAction, oslc_auto:RefreshAction, oslc_auto:TeardownAction, oslc_auto:DeploymentAction (as opposite to teardown, but is redundant with oslc:usage value of an AutomtionPlan for deployment).
    • 14 March 2014 - Updated spec to match 13 March WG resolution to KISS
  10. RESOLVED - Use real action types in examples (both in appendix and in “types of action” section). Blocked by issue #9.
    • 17 Jul 2014 - 9 has been resolved for some time now; automation:TearDownAction is the only specific one for 2.0, and it’s in the text now.
  11. RESOLVED - The “HTTP request with RDF body” currently uses oslc:ContentAsRDF which is intended to be a rdfs:subClassOf cnt:Content, in the same vein as cnt:ContentAsXML. See: http://www.w3.org/TR/Content-in-RDF/. However, I’m not convinced this would be correct to go in the oslc namespace.
    • 7 Jan 2014 - There is also debate about the usefulness of the indirection. See mailing list.
    • 13 Jan 2014 - The content is now considered a “template” in a similar meaning as the template creation dialogs (in OSLC Automation) use the term. We could perhaps have a type or predicate that defines these semantics.
    • Spec updated 2014-01-28 to match resolution from AutomationMeetings20140123
  12. RESOLVED - Action’s oslc:binding occurs = 1:many … does it need to be 0:many in order to meet Automation’s requirement for advertising actions on future resources? (In some cases it may have a binding if there is a dialog that can be executed now).
    • 2 options - either 0:many, or Automation could define that oslc:binding should be rdf:nil for the “future resources” case.
      • Or perhaps both - as some domains/impls might want to advertise “future actions on current resources” (via a predicate other than oslc:action) which wouldn’t need a binding.
    • 26 Feb 2014 - Agreed to set it to 0:many - spec still needs updating
    • 4 March 2014 - Updated spec: Comment in text, resource shape cardinality, comment on oslc:action predicate
  13. RESOLVED - Resolve overlap between overview & description sections. Perhaps the overview ought to follow a specific example, with reference to the points that can be generalised, then the description section have the normative generalised text.
    • 7 Jan 2014 - I believe this is much better now.
  14. RESOLVED - Include general MUSTs for interaction patterns, including MAYs/MUSTs for multi-typing
    • 7 Jan 2014 - I can’t remember what this means - MP.
    • Also under this issue we intend to remove the MUST statements from the “implementation patterns” and replace it with just “To execute this implementation pattern, a consumer does X”. This makes it easier to change that behaviour in the delegated UI dialog for deferred execution case (see automation spec).
    • 4 March 2014 - Last bullet point spec changes made: core, automation
  15. RESOLVED - Clarify the benefit of the loosely-coupled abstractions that Actions provide. (Under the “What are actions?” section). Clarify what it is that consumers do not need to know about. And also what they do. See point 11 in Action resources - implementation patterns mailing list thread.
    • 26 Feb 2014 - Section added a while ago clarifying this.
  16. RESOLVED - Should Interaction Patterns each have their own (single) URI?
    • 26 Feb 2014 - Agreed a while ago that they do not.
  17. RESOLVED - If an AutoRequest pattern binding is executed as the plain “HTTP request with template/RDF body” pattern, how does the consumer know that the action has not completed - it has only been queued? (See mailing list for 15th Jan 2013).
    • 26 Feb 2014 - We will add non-normative text encouraging the use of oslc:usage oslc:default on any bindings where a basic usage (e.g. synchronous execution) needs to be detectable when an alternative usage that the consumer would need to understand (e.g. asynchronous execution, or template creation) is also present. Spec still needs to be updated.
    • 4 March 2014 - Specs updated: core, automation

Editorial issues

  • Consistent capitalisation.
  • Consistent format of normative terms & RDF terms.
  • Make sure all terminology is defined, and no terms are used as if they have specific meanings when none is defined.

Relating to other specs

  • Discovering Actions on resources that don’t exist yet
    • From Resource Shapes & Automation Plans
    • Strawman: handle inside Automation spec, since that’s the only current place with a requirement for this and you need some modeling reference point (like a domain’s model) so specify where the future-available action would be found by a client (which may itself depend on where the “future knowledge” is conveyed). It’s a swamp in the general case.
  • Issue #9
  • Issue #12
  • Clarify intended usage of Actions with Automation Plans from using Automation Plans as in 2.0.

Things to do later on

  • Decide on a target SDO (W3C, OASIS)
  • Bring to Core WG for formal feedback (likely as companion to Automation spec, since Automation’s schedule is tighter than CM’s)
  • Create vocabulary document (update to Core) - draft attached at File:OSLC Core Actions Vocabulary.zip

Convergence Issues

  1. RESOLVED - Add examples legitimizing the use of future actions in resource shapes, in response to Maximo’s feedback in Automation WG wrt actions, where people outside the Core/Automation WGs independently wanted to do this.
  2. RESOLVED - Actions 2.0 Review by Ian. This is being discussed in various meetings: Aug 14, Aug 21, Aug 28th, Sep 18th.
    • 2014-10-09: Some proposals on mailing list.
    • 2015-01-29: II.7.5: ParamterInstance resource table’s rdf:value row changed from value-type “Any” to “AnyResource” to indicate that it should not be a literal.
    • 2015-02-05: II.8.2: Identifiers added for patterns and profiles.
    • 2015-02-09: II.7.4: Added introductory description to “Resource: results” section
    • 2015-02-09: II.8.1: Changed “Action bindings” to singular in specification profile terminology section & overview.
  3. RESOLVED - 2015-01-28: “Re-use by domain specs” section incorrectly states that Automation 2.1 defines an Action type for FutureActions. (Mailing list thread).
    • 2015-01-28: Corrected section to refer to oslc_auto:TeardownAction, not “Future Actions”.
  4. RESOLVED - Removal of requirement for RDF/XML - Mailing list thread
    • 2015-02-09: Requirement (& references) removed