[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Better example but not yet good enough?
OK. Steve 2010/1/25 Jacques R. Durand <JDurand@us.fujitsu.com>: > 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]