[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Handling of "multi-target" TAs
OK, not a good example. But I do think it is intuitive that, if there are two or more objects involved as joint subjects of a predicate because the predicate expresses some relationship between those objects, it makes sense that the relationship itself can be something singular which can be made the target. I just need a decent example. One example statement, say, in an ontology for widgets: "'Small-widget' MUST be a subclass of 'widget'" giving the predicate: 'Small-widget' is a subclass of 'widget' Here the relationship between 'small-widget' and 'widget' is the relationship of subclass. So could, in this example, the target be that relationship? It's hard to see it but I could say "[the class relationship between 'widget' and 'small-widget'] is 'subclass'" 'widget' and 'small-widget' are classes in an ontology and the target is the relationship between them in the ontology. I clearly need a better example though; one where relationships feature significantly. Best regards Steve --- Stephen D Green 2010/1/25 Jacques R. Durand <JDurand@us.fujitsu.com>: > Stephen: > > All your rewordings look fine to me. > But your addition: > > "· Consider the relationship between objects to be the target, here [the difference between the price tag and the promotion price for widget X] which must be zero to pass the test." > > Does not seem to add anything: in this example, the "relationship" is actually concretely represented by the widget Ref# that relate both objects (widget price tag and special offer), which must always be considered and understood. > The other "logical" relationship is the Predicate that you state (price tag value = special offer value), and that is true regardless of the approach - can be seen as a property of the consolidated target when combining both. > > > -jacques > > -----Original Message----- > From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green > Sent: Sunday, January 24, 2010 10:28 AM > To: Jacques R. Durand > Cc: TAG TC > Subject: Re: Handling of "multi-target" TAs > > I'd like to add a further approach in the Guidelines - with a relationship between objects, making the relationship itself the target. Then with a little rewording we'd get: > > "Another case where a predicate is more complex is when its conditional expression involves more than one part of an implementation (or implementations). > In some cases it is clear which one of these objects must be considered the target, while others are just accessory objects. > > Consider the following predicate: "the [widget price tag] matches the price assigned to the widget in its [catalog entry]", where price tags and catalog entries are both items that must follow the store policy (in effect the specification). In this 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] matches the price that is reported on the related [item in list of today's special offers] at the store entrance". Here it is not clear which one of these often-changing labels must be incriminated in the case of a discrepancy (although whichever is lower will likely prevail should a customer complain). > > The following approaches are possible: > > · Consider a combined target, here a pair [price tag and promotion item for widget X] that is identified by the widget reference number. This combination will fail or pass the test. > · Consider the relationship between objects to be the target, here [the difference between the price tag and the promotion price for widget X] which must be zero to pass the test. > · Select arbitrarily one object as the target, while the other will be an accessory, for example, identified by a variable. In a derived test case, a predicate failure will inevitably lead to the examination of both, should the accessory object be causing the failure. > · Write two or more similar test assertions using alternately one object and then the other as the 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/testassertions >> mo >> 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/testassertionm >> ar >> 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/testassertions >> gu >> 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/testassertions >> mo >> del-draft-1-0-4-changes.pdf >> http://www.oasis-open.org/committees/download.php/36042/testassertionm >> ar >> kuplanguage-draft-1-0-5-changes.pdf >> http://www.oasis-open.org/committees/download.php/36041/testassertions >> gu >> 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/testassertions >> mo >> del-draft-1-0-4.odt >> http://www.oasis-open.org/committees/download.php/36045/testassertionm >> ar >> kuplanguage-draft-1-0-5.odt >> http://www.oasis-open.org/committees/download.php/36044/testassertions >> gu >> 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/testAssertionM >> ar >> 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]