[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tag] Comment on Section 4.7 "The Case of Multiple Specifications"
Kevin: I see your point. Multiple specs is a case we want to clearly show support for. Assuming the core of my suggestion is agreeable - namely that: (a)- conformance statements can be used in TA prerequsite or predicate both for multiple ("external") specs and also for a single "internal" (e.g. conformance profiles). (b)- there is a need to cover the possibility of referring explicitly to other TAs in a TA predicate, e.g. in a logical expression like we do for Prerequisite, thus providing another way to express a conformance statement that itself relies on existing Tas. Let me reformulate another proposal: - Title in 4.7 could say "Handling Multiple Specifications and Conformance Statements" (a large part of what is original in this section is about dealing with conformance statements) - add at the end a short sub-section (same level as "Modification of Inclusion"): Titled: "Expressing Conformance statements" That would explain that test assertions themselves can detail the logic of a conformance statement by explicit references to other Tas as opposed to just stating it abstractly. This logic would rely on a boolean expression in the Predicate that composes the outcome of other Tas. Add an example where the Predicate refers to a conformance statement (we had that in an earlier version, and I may have been the one suggesting to remove it !), and show that such a statement can be made either "abstractly" ("widget is conforming to mini-widget spec") or explciitly by a composition of TA outcomes like: Predicate = TA1 and TA2 and (TA3 or TA4) Or: Predicate = TA-set(xyz) (meaning implicitly an AND composition) -jacques -----Original Message----- From: Kevin.T.Looney@Sun.COM [mailto:Kevin.T.Looney@Sun.COM] Sent: Thursday, August 27, 2009 1:49 PM To: Jacques R. Durand Cc: TAG TC Subject: Re: [tag] Comment on Section 4.7 "The Case of Multiple Specifications" Hi Jacques, everyone, Jacques R. Durand wrote: > *Issue*: Section 4.7 seems to focus on the case of "multiple > specifications" but really its content is about using higher-level > statements (conformance) in TAs. It is relevant even when dealing with > a single specification that defines different conformance profiles or > high-level properties that cover several normative statements. I understand that you 'can generalize' this section to cover other situations (eg. statements regarding conformance profiles or other high level properties), but is it really useful to do this? Multiple specifications were originally drawn out because it is quite common for specifications to reference each other, and it is important when encoding TAs to describe the context of the assertion in this closure of specifications. I think there is reasonable value in illustrating this situation in the guideline. > > *Proposal*: > > The title of this section 4.7 "The Case of Multiple Specifications" > may not be well-chosen: the section is really about TAs making higher > level statements (conformance statements) in their Predicate or > Prerequisite. > These conformance statements could refer to other specifications > ("multiple specs") but not necessarily: it could be several conf > profiles from the same big specification. > > - Title could refocus on the Test Assertion itself by saying: > "Higher-Level test Assertions", > because such TAs address or refer to entire conformance statements > (either to an external spec, or just a conformance profile to the > current spec), not just a simple normative statement. While I agree that this is a reasonable generalization, I would hate to lose readers who need to solve multi-spec encoding problems in this generalization. I think there is value is specifically focusing on encoding TAs over multiple specs. Would it be reasonable to describe somewhere else that "there are other types of higher-level conformance statements that can be described in a manner similar to how multiple specifications are handled"? > > - The section could mention the possibility to refer to other test > assertions inside the Predicate (not just in the Prerequisite): > e.g. a "high-level" TA can have a Predicate that says: (TA1 AND TA2 > AND (TA3 OR TA4)) . Such a TA can address a conformance profile, when > such a profile can be defined by test assertions. The other > possibility - the only one we describe currently - is to make an > abstract conformance statement in the Predicate (but this only works > if such a conformance statement is already well-defined... and > sometimes precisely it is defined by a high-level expression over the > outcome of several TAs). Again, I don't object to these type of generalizations, but possibly in a different section. > > - The section can make the link with the "Test Assertions for > Properties" section 4.3, showing how a complex property (often > indistinguishable from a conformance profile) can be defined by a > [higher-level] TA, in complex cases where several TAs are needed. > See my email 8/4: we could illustrate in 4.7 the case where > "medium-size" is defined by a separate TA that refers two low-level > TAs - one on widget weight, one on widget size. > > Regards, > Jacques Regards, Kevin L
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]