OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[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]