History   View   Links to this page 2012 September 11 | 01:28 pm

Time: 10:00AM Eastern US (contact MichaelFiedler if you’d like to participate)

The Automation meetings alternate times each meeting to accommodate the global team.

Agenda

  • Main agenda items:
    • Review minutes from AutomationMeetings20120823
    • Review Rational Dev Council feedback
    • Governance changes
      • Workgroup Participation Agreement from all contributors
      • http://open-services.net/legal-agreements/automation-wpa
    • Specification issues
      • Adoption issue: Can oslc.properties be made something other than a MUST
        • See mailing list thread here: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-August/000273.html
        • Core spec: MAY
        • QM, RM, CM, AssetM: MUST (had Core 1.0 versions of their specs)
        • ArchitectureM: MAY
      • Responses to cancellation request. Possible proposal:
        • 200 (OK) if successful (maybe 202(Accepted) if long-running)
        • 501 (Not implemented) if provider does not support cancel
        • 502 (Bad Gateway) if a cancelation attempt is completed but fails upstream.
        • In all cases, consumer should check state of the Request or Result.
      • dcterms:creator guidance for Automation Results
      • Open items for finalization - status
        • Resource shapes
        • Examples
        • Reference implementation
        • Test suite
    • Times for future bi-weekly meetings
    • Suggestions for additional topics in the Guidance section of the specification
    • Implementation updates
    • Next meeting:
      • 20 September at 10AM Eastern US time

Minutes

Attending: Michael Fiedler, David Brauneis, Paul McMahan, Jing Qian, Dan Berg

  • Discussed governance changes
    • Need to ensure substantial contributors join the workgroup
  • Discussed feedback from Rational dev council meeting
  • Spec issues:
    • Should oslc.properties be a must
      • Intended for GETs of individual resources
      • Does not make sense for some scenarios (e.g. synch scenario when results are returned in full in the response)
      • Add wording to the spec on supporting query capability in cases where results are not available
    • Responses to cancellation request
      • Discussed proposal above in agenda. Too confusing
      • Alternate proposal: Use a 500 response code and add guidance on using oslc:error to convey the reason cancellation failed. Also add wording that clients should check the state predicates after requesting a cancelation.
    • dcterms:creator guidance for Automation Results
      • Add working that this is expected to be either
        • The FOAF Person on behalf of who this automation is being run. Could be the requester or a user the automation is running under
        • Possibly a FOAF Agent if the provider itself is initiating creation of the result.
  • Future meetings
    • Move to bi-weekly
    • Use the 10AM Eastern US time to ensure inclusion of colleagues in China and India