[Oslc-Automation] Definition of "parameter"

[John Arwe]

> 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 at IBMUS
Cc:     oslc-automation at open-services.net, 
oslc-automation-bounces at open-services.net
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 at IBMUS
To:     oslc-automation at open-services.net
Date:   01/23/2012 12:54 PM
Subject:        Re: [Oslc-Automation] Definition of "parameter"
Sent by:        oslc-automation-bounces at open-services.net



> 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
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120123/ff973aee/attachment-0003.html>