[Oslc-Automation] Definition of "parameter"

[Paul McMahan]

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