“From “outside” the 2.1 draft looks very good, but gets increasingly harder to grasp. I’m a bit concerned that both the automation specification and OSLC as a whole is growing at a speed and in a form, where the original goal of simplicity and sticking to what is necessary for or needed by most applications, is not fulfilled anymore.” - Email 9th May. Response 14th May.
Next meeting 3rd July (subject to any business to discuss - may be cancelled 24h beforehand)
AOB
Actions from previous meetings
John - To talk to people in Tivoli for SM about interest in Availability spec.
Minutes
Attendance
Resolutions passed
None
Minutes
To keep meeting short, will only cover the “Availablility” point from the agenda:
Availability
Use of OSLC Actions’ profiles/patterns: best if we have one pattern that providers MUST provide to be compliant, to reduce burden on consumers. This should probably be the AutomationRequest pattern. The fact that this is asynchronous shouldn’t be a problem, as consumers who want to be loosely-coupled cannot assume providers’ actions will be synchronous.
How does the consumer know which property will be changed, and to what value? Tim’s current plan (for his prototype) is to have a single Availability action that takes the target state as a parameter. Question was raised about how the consumer knows what the parameter is and what the values will be - will they be specified in the spec?
Is it correct to define a new action type like this? Defining a new action type is good to identify a particular type or class of actions. However, whether this particular definition is correct, and how abstract it should be, will be more evident when we see a definition of it in the spec or vocab.
Next steps:
TF to upload next draft of Availabiilty spec Tuesday 1st July.
Other members to read & provide feedback on mailing list.
Next meeting: 17th July (due to unavailability of members on July 10th).
