Re: [tag] Added text about Variables in TA Guidelines

[stephen.green@systml.co.uk]

OK I've updated the verbiage of 3.7 - a bit crudely worded
for now but hopefully the content itself is still on track.
-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice



Quoting stephen.green@systml.co.uk:

> Many thanks David for good feedback comments on variables
> and for the example which ties in nicely too with issue
> i031 to provide a way to formulate a TA whose purpose is
> to determine an output value while still itself evaluating
> to a boolean value. The TA determines that the encoding
> has value DEFAULT-ENCODING and DEFAULT-ENCODING is itself
> a variable determined by in input value - input to the TA
> that is. I like it. I'll add the example. I guess we'll
> need a short sentence to introduce it. I'll formulate one
> but would appreciate it if you'd look it over when posted.
> Thanks. Maybe we can lead from here to a solution on not
> just issue 31 but also the wider application of this kind
> of TA to not just determine a predicate value but other,
> non boolean values too.
> -- 
> Stephen D. Green
>
> Partner
> SystML, http://www.systml.co.uk
> Tel: +44 (0) 117 9541606
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>
>
>
> Quoting david_marston@us.ibm.com:
>
>> I think Stephen's verbiage about variables is headed in the right
>> direction. It might help to talk about scope a little bit more.
>>
>> In the case of the geo-political location or (my last example) the default
>> collation, it is significant that the variable is set once and applies
>> globally across all TAs that make reference to it. The same would apply to
>> modules/profiles/levels: once the IUT has been assessed as implementing a
>> certain level or aiming to support a particular profile or supporting
>> certain modules (or not), then all the relevant TAs can be filtered and
>> their implications properly cascaded. This is an operation that should
>> only happen once per run of a test suite. Thus, a standardized design for
>> TAs helps improve the design of test harnesses because the design can be
>> based around resolving all the variables before running any test cases
>> that depend on those variables.
>>
>> The earlier example of the fuse rating is more local in scope, but may
>> still be an interesting usage for variables.
>>
>> Finally, I note that your example does not have a tie between the variable
>> input to the TA and the result of the test. The default-encoding example
>> shows this situation, so I think you should add this as another example.
>> NOTICE that this example does NOT use the variable in a pre-req, hence it
>> is significantly different from the geo-political widget example.
>> Variable: 'DEFAULT-ENCODING' the identification of the encoding used on
>> XML output when no other encoding has been given. Type is string, because
>> there is no universal enumeration of all possible encoding IDs.
>> TA id: frammis-1
>> Target: any frammis
>> Normative Source: specification requirement 105, part 17
>> Predicate: If [the frammis] was not dynamically told which encoding to
>> use, its output has DEFAULT-ENCODING encoding.
>> Prescription Level: mandatory
>> To summarize: variables have a role as both inputs to and outputs of a TA.
>> .................David Marston
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php