> In fact, could we not define a ResultContribution type that is a name-value pair???
That's a good point. But at least in my mind a contribution and an output parameter are conceptually different, in which case distinguishing them with different property names could still be warranted. I'm assuming that a contribution would typically be more like an artifact produced during the automation that has structure (represented as RDF triples), could contain references to other resources, and has considerations to take into account such as its lifecycle characteristics, whether its local or remote to the automation provider, etc. Whereas an output parameter is typically not an artifact and is intentionally symmetrical with the concept of input parameter (i.e. the name/value concept). Best wishes, Paul McMahan Rational Quality Manager From: David N Brauneis/Raleigh/IBM@IBMUS To: [email protected] Date: 01/06/2012 11:13 AM Subject: Re: [Oslc-Automation] Parameters: need for input and output parameters? Sent by: [email protected] Paul, I guess that I was not making the assumption that contribution is necessarily a "resource" but that it could be... In fact, could we not define a ResultContribution type that is a name-value pair??? Regards, David ____________________________________________________ David Brauneis STSM, Rational Software Delivery Automation Chief Architect email: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Paul McMahan/Raleigh/IBM@IBMUS To: [email protected] Date: 01/06/2012 10:33 AM Subject: Re: [Oslc-Automation] Parameters: need for input and output parameters? Sent by: [email protected] I was thinking that the difference between contributions and output parameters is that a contribution is a "resource" - i.e. an autonomous artifact with properties of its own that can be inlined in the result or referenced via URL. On the other hand, output parameters are name/value pairs that can be used to facilitate further downstream automation. For example, another automation request might be created with input parameters copied from the automation result's output parameters. Another scenario could be if the provider actually changed the value of a particular input parameter during the automation and needs to make a record of that. If the parameters were not distinguished as input vs. output then there wouldn't be any way to denote that the provider had used a different (or maybe just more refined) value than what was provided as input. Best wishes, Paul McMahan Rational Quality Manager From: David N Brauneis/Raleigh/IBM@IBMUS To: [email protected] Date: 01/06/2012 10:10 AM Subject: Re: [Oslc-Automation] Parameters: need for input and output parameters? Sent by: [email protected] Michael, Thanks for taking the time to write this information up to the give the group a starting point for the discussion going forward... I'm mostly in agreement with everything that you have written down so far with the exception of the outputParameters. I'm having a little trouble getting my head around the need for an outputParameter and how that is really different than a ResultContribution. Perhaps I am just being a little dense but I was thinking that the parameters (name-value pairs) would be input with the request and would be read-only in the result but that anything created during processing (like an MD5 checksum) would be a ResultContribution. Am I thinking about this completely differently than everyone else? Regards, David ____________________________________________________ David Brauneis STSM, Rational Software Delivery Automation Chief Architect email: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Michael F Fiedler/Durham/IBM@IBMUS To: [email protected] Date: 01/05/2012 09:22 PM Subject: [Oslc-Automation] Parameters: need for input and output parameters? Sent by: [email protected] An important point came up at the end of today's call around the zero-many *parameter* attribute on Automation Plans, Requests and Results. There was sentiment that there needs to be a distinction between input parameters and output parameters for Results, and possibly for each of the resources. Continuing the discussion, here are some thoughts on what the usage might be for each artifact: Automation Plan: The parameters are likely to all be input parameters. Some may have default values, others may be empty. These provide consumers with a starting point of what parameters are required for successful request creation. Are there scenarios for output parameters on the Plan? None are occurring to me. Automation Request: When creating a Request, consumers provide the input parameters for actual automation execution (or at least the subset of parameters they have control over). There is likely a scenario for the service provider adding additional parameters to the request, but they would still be input parameters. Is there a scenario for output parameters on the Request artifact? Possibly as the result of processing that the service provider does to "accept" the Request? Automation Result: The input parameters here would be a "final" record of what parameters were used to run this automation and create the result. As discussed today, there also seems to be a strong case for output parameters on the result. I.e., as the automation executed, certain information, apart from the main result contributions, is generated and needs to be captured in the result - especially for consumers of the result such as downstream automations. Examples might be the MD5 hash of a binary which was the result of an automation or the filesystem location of the primary automation result artifact. We never reached the point of proposing it, but I think the direction was to propose 2 sets of parameter attributes/predicates: inputParameter and outputParameter. From the descriptions above, outputParameter might only be appropriate for a subset of the artifacts, but could be included on all for symmetry. Comments? We'll discuss in the next meeting, but a discussion on list would be fine as well. Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
