[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Better example but not yet good enough?
Stephen: That's better.... But still one could argue that the actual target in that case is the widget that is holding all these buttons! So I think that could be seen as a fourth approach to handling this: instead of considering the combination of objects (and also instad of the "relationship") as the target, when all these objects are parts of a larger component - the widget - this component can be chosen as the target. Indeed, your spec requirement will say something like: "On a widget of type XYZ, the blue button, the black button and the red button MUST be equidistant" Because again, the target must be an "implementation" of the spec - and your case for something as abstract as a "distance" for a target, is really borderline... -jacques -----Original Message----- From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green Sent: Monday, January 25, 2010 2:26 PM To: Jacques R. Durand Cc: TAG TC Subject: Re: Handling of "multi-target" TAs One last try on this. How about a predicate with three subjects: "the blue button, the black button and the red button are equidistant" Here each button is an object which could equally be a target but we would say the target is the distances between the buttons "[the distances between the red, blue and black buttons] are equal" so the 'relationships' between the objects (distances) become the target (and maybe this is not really a combination target as such) Best regards Steve --- Stephen D Green 2010/1/25 Stephen Green <stephen.green@documentengineeringservices.com>: > OK, thanks > > Steve > > > > > 2010/1/25 Jacques R. Durand <JDurand@us.fujitsu.com>: >> Stephen: >> inline >> >> -----Original Message----- >> From: stephengreenubl@gmail.com [ >> mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green >> Sent: Monday, January 25, 2010 4:59 AM >> To: Jacques R. Durand >> Cc: TAG TC >> Subject: Re: Handling of "multi-target" TAs >> >> Looking again at >> >>> "In cases where the predicate of a test assertion needs to use more >>> than one object (part of an implementation), it is possible to >>> consider their composition as the target. However in many cases, one >>> of them must be selected as the target, while the other objects are >>> accessory to the test. Such objects can be referenced in the >>> predicate or prerequisite using variables." >> >> Is there a way we can improve these statements as normative >> statements, appropriate for the model spec? >> >> Firstly, as before we may need to tighten our semantics for 'target', >> 'object' and 'accessory object'. Maybe we do not need to state these >> semantics, just to be clear about them as background to the >> statements we make (?). >> >> <JD> How about: >> >> "The predicate may express a condition over more than one object. >> These objects are either parts of an implementation or external >> resources. A unique target object is still required by this model. In >> such a case, either the target is defined as the combination of >> objects that are expected to satisfy the predicate, or one of these >> objects may be selected as the target while the other objects are >> just considered as accessory to the test. Such objects may be referenced in the predicate or prerequisite using variables." >> >> Secondly we are presenting a choice for how a target relates to a >> test assertion and to a predicate in particular: Can we improve the >> two normative statements to this effect? In the second case/choice of >> approach we offer we have the word 'can' which maybe we need to >> replace with a normative term such as 'may': >> >> <JD> Right. >> >> "However in many cases, one of them must be selected as the target, >> while the other objects are accessory to the test. When there is a >> requirement to select a single object as a target from several >> objects, the other, accessory objects <b>may</b> be referenced in the >> predicate or prerequisite using variables." >> >> Likewise for the first statement >> >> "In cases where the predicate of a test assertion needs to use more >> than one object (part of an implementation), their composition >> <b>may</b> be treated as the target." >> >> Then the second statement would follow as: >> >> "However in many cases, just one of several objects must be selected >> as the target, while the other objects are accessory to the test. >> When there is a requirement to select a single object as a target >> from several objects, the other, accessory objects <b>may</b> be >> referenced in the predicate or prerequisite using variables." >> >> I would tend to add: >> >> "Alternatively, the relationship between the objects <b>may</b> >> itself be treated as a single target." >> >> <JD> I am afraid that this could be confusing: a "relationship" is >> often understood as just the link between two objects, or the >> property that relates them together: here, the "widget ID" can be >> seen as this link - yet the predicate looks at more data than the >> link data. Isn't a "combination of objects" more intuitive, even if less formal?. >> >> >> >> Best regards >> >> Steve >> --- >> Stephen D Green >> >> >> >> >> 2010/1/24 Stephen Green <stephen.green@documentengineeringservices.com>: >>>> >>>> "In cases where the predicate of a test assertion needs to use more >>>> than one object (part of an implementation), it is possible to >>>> consider their composition as the target. However in many cases, >>>> one of them must be selected as the target, while the other objects >>>> are accessory to the test. Such objects can be referenced in the >>>> predicate or prerequisite using variables." >>> >>> I agree, provided the 'must' in "one of them must be" is not a >>> normative MUST since there are alternatives (as considering "the >>> composition as the target" or, in my example just posted, >>> considering the relationship between two or more objects as the target). >>> >>> I do wonder whether we have defined clearly what a 'target' >>> actually is - the rationale / reason for having one object in a >>> predicate distinguished and called a 'target'. We have done so >>> implicitly (something in an implementation which is a focus for >>> testing and/or subject of the assertion, though I'm not sure we are >>> clear whether test target or assertion subject is the primary focus). >>> Should/could this be more explicit. Why, exactly, explicitly, does a >>> particular object in a predicate/assertion need to be (and qualify >>> for >>> being) denoted a 'target'? >>> >>> Best regards >>> >>> Steve >>> --- >>> Stephen D Green >>> >>> >>> >>> >>> 2010/1/23 Jacques R. Durand <JDurand@us.fujitsu.com>: >>>> Stephen: >>>> >>>> Looks good to me except for the handling of "multi-target" Tas: >>>> >>>> In TA model you add: >>>> >>>> "In cases where more than one target is relevant to a test >>>> assertion, additional targets may be treated as accessory objects >>>> and reference to these made using variables (see variables section >>>> below) and combined to form a compound target expression." >>>> >>>> I think the following updates are needed: >>>> - we need to be more assertive on what is to be done (may -> must : >>>> the user does not have the choice !) >>>> - also explain a bit more the "multi-target" situation, while >>>> avoiding to call the additional objects "targets" >>>> - and finally, the target of such a TA is in general NOT the >>>> compound of these objects (though it may): >>>> >>>> "In cases where the predicate of a test assertion needs to use more >>>> than one object (part of an implementation), it is possible to >>>> consider their composition as the target. However in many cases, >>>> one of them must be selected as the target, while the other objects >>>> are accessory to the test. Such objects can be referenced in the >>>> predicate or prerequisite using variables." >>>> >>>> I suggest we add a similar note in the Guidelines, a little more >>>> verbose with a little inline example, say at the end of 4.1 >>>> "Complex Predicates", since this issue is normally coming up when >>>> people have to define a predicate using several obejcts: >>>> >>>> "Another case where a predicate is more complex is when its >>>> conditional expression involves more than one part of an >>>> implementation(s). In some cases it is clear which one of these >>>> objects must be considered as the target, while others are just >>>> accessory objects. >>>> Consider the following predicate: "the [widget price tag] is >>>> matching the price assigned to this widget in its [catalog entry]", >>>> where price tags and catalog entries are both items that must >>>> follow the store policy (the specification). In that case it may be >>>> reasonably assumed that the "catalog" content is authoritative over >>>> the price tag. The price tag can then be considered as the test >>>> target, while the accessory object may be identified by a variable >>>> which is then used in the predicate. >>>> >>>> Other cases are more ambiguous. >>>> Consider the following predicate: "the [widget price tag] is >>>> matching the price that is reported on the related [item in >>>> promotion list] at the store entrance", where it is not clear at >>>> which one of these often-changing labels must be incriminated in >>>> case of discrepancy (although whichever is lower will likely >>>> prevail should a customer complain). >>>> >>>> Three approaches are possible: >>>> >>>> (1) Consider a combined target, here a pair [price tag and >>>> promotion item for widget X] that is identified by the widget ref >>>> number. This combination will fail or pass the test. >>>> (2) Select arbitrarily one object as the target, while the other >>>> will be accessory, e.g. identified by a variable. In a derived test >>>> case, a predicate failure will inevitably lead to examine both, >>>> should the accessory object be causing the failure. >>>> (3) Write two similar test assertions using alternately one object >>>> and the other as targets." >>>> >>>> For review... >>>> >>>> Jacques >>>> >>>> >>>> -----Original Message----- >>>> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] >>>> On Behalf Of Stephen Green >>>> Sent: Friday, January 22, 2010 11:56 AM >>>> To: TAG TC >>>> Subject: [tag] Further iteration (any more changes/discussion?) >>>> >>>> Now we do seem to be nearing drafts we can vote on: >>>> >>>> Model: >>>> http://www.oasis-open.org/committees/document.php?document_id=36047 >>>> http://www.oasis-open.org/committees/download.php/36047/testasserti >>>> on >>>> smo >>>> del-draft-1-0-4.pdf >>>> >>>> Markup: >>>> http://www.oasis-open.org/committees/document.php?document_id=36048 >>>> http://www.oasis-open.org/committees/download.php/36048/testasserti >>>> on >>>> mar >>>> kuplanguage-draft-1-0-5.pdf >>>> >>>> Guidelines: >>>> http://www.oasis-open.org/committees/document.php?document_id=36049 >>>> http://www.oasis-open.org/committees/download.php/36049/testasserti >>>> on >>>> sgu >>>> idelines-draft-1-0-9-6.pdf >>>> >>>> If you just want to see the diffs from previous internal review >>>> >>>> http://www.oasis-open.org/committees/download.php/36043/testasserti >>>> on >>>> smo >>>> del-draft-1-0-4-changes.pdf >>>> http://www.oasis-open.org/committees/download.php/36042/testasserti >>>> on >>>> mar >>>> kuplanguage-draft-1-0-5-changes.pdf >>>> http://www.oasis-open.org/committees/download.php/36041/testasserti >>>> on >>>> sgu >>>> idelines-draft-1-0-9-6-changes.pdf >>>> >>>> Is there more to discuss? Are there more comments? Can we vote on >>>> these drafts? >>>> >>>> I'm not sure exactly how this works but I think we would have to >>>> vote on the editable source (ODT) versions: >>>> http://www.oasis-open.org/committees/download.php/36046/testasserti >>>> on >>>> smo >>>> del-draft-1-0-4.odt >>>> http://www.oasis-open.org/committees/download.php/36045/testasserti >>>> on >>>> mar >>>> kuplanguage-draft-1-0-5.odt >>>> http://www.oasis-open.org/committees/download.php/36044/testasserti >>>> on >>>> sgu >>>> idelines-draft-1-0-9-6.odt >>>> >>>> and the schema: >>>> http://www.oasis-open.org/committees/document.php?document_id=35840 >>>> &w >>>> g_a >>>> bbrev=tag >>>> http://www.oasis-open.org/committees/download.php/35840/testAsserti >>>> on >>>> Mar >>>> kupLanguage-draft-1-0-3.xsd >>>> >>>> and namespace document: >>>> http://www.oasis-open.org/committees/document.php?document_id=35788 >>>> &w >>>> g_a >>>> bbrev=tag >>>> http://www.oasis-open.org/committees/download.php/35788/namespace.z >>>> ip >>>> >>>> >>>> >>>> Best regards >>>> >>>> Steve >>>> --- >>>> Stephen D Green >>>> >>>> ------------------------------------------------------------------- >>>> -- To unsubscribe from this mail list, you must leave the OASIS TC >>>> that generates this mail. Follow this link to all your TCs in >>>> OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups. >>>> ph >>>> p >>>> >>>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]