> But we have talked about how parameters "move" across the transition from automation plan --> automation request --> automation result.
Right, and (channeling Dan B) that's why in that context we have often cited the need to *refer to* the value of a parameter from somewhere else. Especially in the deployment space, it's not the parameter names that matter, it's that Plan A's parameter Foo == Plan B's parameter Bar. When you're in "template space", you want that to be a reference. When you've instantiated the template, it may at some point change from a reference to a by-value copy (via some binding process), but it might just as easily remain a reference (for traceability) as long as the vocabulary for making such references is shared/standard knowledge. After everything has run, whether "former references" remain references or are converted to by-value copies is something I'd guess we leave as implementation choice. At least I see no obvious reason to constrain it. I'm hesitant to make value judgements about "unnecessary duplication" without understanding the expected frequencies of the scenarios. It's certainly fair to say that forcing by-value copies everywhere would optimize certain cases better than others. But if 'parameter' is a resource definition and we allow those to be present as inline|reference, then I think it would at least be true that in a single document one could serialize the contents once and refer to it from all other places in the same document, so the level of potential waste appears to be largely under the control of the implementation. If we're talking about what's inside a repository of implementation plans, well if storing those as triples is inefficient I might trot out the "if it hurts, then don't do that" argument... just because I expose RDF does not force me to have a triple store (or not) behind my interface layer. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Paul McMahan/Raleigh/IBM To: John Arwe/Poughkeepsie/IBM@IBMUS Cc: [email protected], [email protected] Date: 01/23/2012 02:32 PM Subject: Re: [Oslc-Automation] Definition of "parameter" 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
