[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Added text about Variables in TA Guidelines
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]