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

[Stephen Green <stephen.green@documentengineeringservices.com>]

Please could I now chase some text summing up what has
been agreed here. I'd like to include it in the next iteration
of guidelines - 1.0.8.

Many thanks

Steve
---
Stephen D Green




2009/9/15 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>