Re: [tag] Comment on Section 4.7 "The Case of Multiple Specifications"

[Kevin Looney <Kevin.T.Looney@Sun.COM>]

Hi Jacques,

     In general - I think your proposal is good.

    Question:  Do we really need to "glom" the two topics together in 
the same section?

                    I'm guessing we could easily separate them (eg. 4.7 
multiple specs, 4.8 Conformance Statements), and begin the conformance 
statement section with something like:  "We can handle conformance 
statements in a similar way to multiple specifications (because 
referenced specs are subset of conformance statements)"   - or even 
reverse the order of these sections.

     I'm suggesting this because I think we can keep clarity by having 
these as 2 separate sections, and reduce the amount of thrash re-working 
what we have already described for multiple specs.

Other than this, I can see the value of describing conformance 
statements - especially with examples to go along with this.

Regards,
Kevin L

Jacques R. Durand wrote:
> 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
>
>
> ---------------------------------------------------------------------
> 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
>
>