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

Agenda

* Main agenda items:

• Review minutes from AutomationMeetings20120628
• Specification issues
  • Automation State and Verdict open issues
  • Need for Automation "type" designation.
    • Thread starts here
    • Proposal from PaulMcMahan is here
• Specification comments/questions
• Specification review comments
• Specification status and Implementation plans
  • update vocabulary to match spec
• Next meeting:
  • Thursday, 19 July at 1PM Eastern US - John Arwe will chair.

Minutes

Attending: Michael Fiedler, Paul McMahan? , John Arwe, David Liu, Jing Qiang, Vaibhav Srivastava

Specification issues

• Review of AutomationMeetings20120628 updates to the specification. Introduced changes and requested reviews
  • new oslc_auto:verdict values
  • new Guidance section with a) guidance on canceling Automations and b) Request/Result consistency table
    • Comment: remove SHOULD from informative section
• Remainder of discussion centered around need for Automation providers to identify the type of automation supported
  • Two scenarios identified
    • Administrative scenario - when administratively linking two service providers, need the ability to determine what automation capabilities/sub-domain a provider exposes.
    • Runtime/UI scenario - need the ability to present an appropriate creation or selection dialog based on context in the consumer
    • TODO: MichaelFiedler to document the scenarios and solicit comments
  • Proposed solution
    • Add a "hash" qualifier to oslc:domain in the service provider catalog document and the service descriptions in the service provider document. Example

<ServiceProviderCatalog>

    <oslc:domain rdf:resource="http://open-services.net/ns/auto#Test" />
    <oslc:domain rdf:resource="http://open-services.net/ns/auto#Deploy" />

    <oslc:serviceProvider>
          <oslc:ServiceProvider>
                 <service>
                     <Service>
                         <oslc:domain rdf:resource="http://open-services.net/ns/auto#Test" />
                         <creationFactory rdf:resource="..."/>
                         <queryCapability rdf:resource="..."/>
                         <selectionDialog rdf:resource="..."/>
                         <creationDialog rdf:resource="..."/>
                     </Service>
                 </service>
                 <service>
                     <Service>
                         <oslc:domain rdf:resource="http://open-services.net/ns/auto#Deploy" />
                         <creationFactory rdf:resource="..."/>
                         <queryCapability rdf:resource="..."/>
                         <selectionDialog rdf:resource="..."/>
                         <creationDialog rdf:resource="..."/>
                     </Service>
                 </service>
          </oslc:ServiceProvider>
    <oslc:serviceProvider>

</ServiceProviderCatalog>

• • Some alternatives discussed:
    • dcterms:subject
      • Some felt this might not be specific enough - used as a general purpose tag in OSLC
    • oslc:usage
      • A possibility. Used on creation factories, query capabilities and dialogs.
      • Possibly does not address administrative scenario where there is a need to see "type" at provider level (see above)
  • Document alternatives and discuss. Actions (for MichaelFiedler):
    • Create wiki page with provisional language
    • Define a set of URIs in the Automation spec with language for 3 proposed sub-domain types: Build, Test and Deploy
    • Include language that these oslc:domain hash qualifiers are optional
      • Consumers must be prepared to deal with service providers who do not quality oslc:domain
    • Solicit feedback

• Vocabulary updated. See AutomationVocabulary
• John Arwe will chair the 19 July meeting. Workgroup will determine if 26 July meeting required.
• Add any issues impacting convergence to the agenda