That's a really helpful observation. If we don't expect the parameters to be reused across multiple automation resources then its safer to assume that the properties are implicitly scoped. We haven't talked about multiple automation plans sharing the same parameters, so my example scenario may be out of scope for V1. But we have talked about how parameters "move" across the transition from automation plan --> automation request --> automation result. If we assume that properties are implicitly scoped then each resource may need to make copies of its parameters. This could lead to some unnecessary duplication within a RDF model that describes multiple automation resources, such as one that described the full automation sequence. But perhaps the simplicity this approach affords is worth that cost. I certainly agree with Charles' earlier email saying that we don't want to go too far in establishing a pattern of pushing any volatile properties into relationship names.
Best wishes, Paul McMahan Rational Quality Manager From: John Arwe/Poughkeepsie/IBM@IBMUS To: [email protected] Date: 01/23/2012 12:54 PM Subject: Re: [Oslc-Automation] Definition of "parameter" Sent by: [email protected] > 3) Your examples shows a parameter definition resource being used across multiple Automation Plans. That's the nub of the discussion I think. Two APs, each with a single identically named parameter -- so is it really 1 parameter or 2? It's another version of the relationship between a property and a class that uses the property. Is the class (AP) providing a single namespace that scopes all its properties (so any apparently identical property names across different classes are still in fact unique), making the property's definition wholly contained within the class, or is wider property definition re-use possible and therefore the relationship is more nuanced/layered? I'd suggest that (for AP parameters at least) the scenario we must support is the one with no re-use. I make up my own parameter names, their definitions are wholly specific to the AP instance, period. "Definition" then includes things like required-ness. If/when we have concrete scenario (s) to re-use parameter definitions themselves, then we can talk about the more complex/layered relationships that may exist between a parameter definition that can exist independently of any AP and the AP(s) that re-use (perhaps, simultaneously refine in the context of a given AP). We might possibly say that we do not wish to *prevent* such re-use in the future, but I do not know of anything more that we must say today. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
