[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Handling of "multi-target" TAs
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/testassertionsmo 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/testassertionmar 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/testassertionsgu 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/testassertionsmo del-draft-1-0-4-changes.pdf http://www.oasis-open.org/committees/download.php/36042/testassertionmar kuplanguage-draft-1-0-5-changes.pdf http://www.oasis-open.org/committees/download.php/36041/testassertionsgu 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/testassertionsmo del-draft-1-0-4.odt http://www.oasis-open.org/committees/download.php/36045/testassertionmar kuplanguage-draft-1-0-5.odt http://www.oasis-open.org/committees/download.php/36044/testassertionsgu idelines-draft-1-0-9-6.odt and the schema: http://www.oasis-open.org/committees/document.php?document_id=35840&wg_a bbrev=tag http://www.oasis-open.org/committees/download.php/35840/testAssertionMar kupLanguage-draft-1-0-3.xsd and namespace document: http://www.oasis-open.org/committees/document.php?document_id=35788&wg_a bbrev=tag http://www.oasis-open.org/committees/download.php/35788/namespace.zip 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.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]