Re: [tag] comments on the TA model

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

I've completed changes for those comments of Jacques and
Kevin to which I've indicated agreement.

I welcome discussion about the other comments for with a
view to any further edits before I upload the documents. Of
particular note would be a change to simplify the
normativeSource/derivedSourceItem as this would require
changes to all three documents and the schema and
examples. I still do not understand how it would work if people
derived text from tables, etc and needed to both relate the
text and provide references to the source(s) from which it was
derived - at least I don't see how it would work with a simpler
structure for derivedSourceItem.

Best regards

Steve
---
Stephen D Green




2010/1/20 Stephen Green <stephen.green@documentengineeringservices.com>:
> I've changed my mind about [10]. I think the
> word 'alternative' refers to the 'way' a source
> item is handled. There are alternatives to the
> way you handle the source items.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/20 Stephen Green <stephen.green@documentengineeringservices.com>:
>> response inline
>>
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2010/1/19 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>>
>>> Here is some late (sorry..) comments on the TA model: only minor things.
>>>
>>> Nothing I see that would justify waiting any longer for a CD vote and PR.
>>>
>>> However, if we have time to go through (dome of) these in the meeting,
>>> resolution is obvious and
>>> could easily be left to the Editor, if we agree.
>>> Overall, I feel very good about this document - very crisp and precise.
>>>
>>> As a priority, I'd focus on these two that may be more than editorial:
>>>
>>> [11]
>>> [19]
>>>
>>>
>>> Regards,
>>> Jacques
>>>
>>>
>>> --------------------------------
>>> Section 1:
>>>
>>> [1]- def of "association" is not very clear... it seems recursive.
>>
>> I agree, will change to:
>>
>> The term “association” is used of an entity which is grouped by a
>> class and is itself based on a class (rather being based on a
>> primitive or simple datatype).
>>
>>>
>>> [2]- def of Test Case : could include a mention that "Test Cases usually are
>>> grouped
>>> in a Test Suite."
>>>
>>> --------------------------------
>>> Section 3.1:
>>>
>>> [3]- Informal names for TA parts: qualifying the names with "Test Assertion"
>>> (e.g. Test Assertion Target) seems redundant, and inconsistent: we only do
>>> that for
>>> Test Assertion Identifier and Test Assertion Target (why?). Suggest to
>>> remove.
>>
>> OK, but we have this kind of thing in the Guidelines where it seems
>> more appropriate (e.g. we have 'TA Id', not simply 'Id'). I have had a few
>> tussles with where 'Test Assertion' is redundant and wheere it is
>> necessary to eliminate ambiguity and vagueness.
>>
>>
>>>
>>> [4]- Inside the def of Target: suggest to add a "note: a test assertion may
>>> concern
>>> more than one [part of] implementation. It is recommended however to select
>>> only
>>> one of these as the Target."
>>
>> Not really sure I agree. I think it may be an oversimplification
>> in some ways to only have a single target - in logical terms.
>> I've read opinions that a predicate can have more than subject
>> or target when the predicate describes a relationship between two
>> subjects/targets:
>> e.g.
>> [A] is less than [B]
>>
>> I agree we have in the markup simplified it by rolling all targets
>> into one and for the sake of tools convenience decided that
>> in some implementations just one target can be denoted as
>> 'primary'. However, I could imagine other ways to implement
>> the model which it seems unfair to restrict in this way. I'm
>> thinking some representations could be optimised for scenarios
>> where relationships between two or more targets are the focus,
>> e.g. TAs about tables/fields in a relational database or classes
>> in an API. I'm not even sure we make a normative requirement
>> about this in the markup. Multiple targets I'm OK with but not
>> sure we should insist on one being denoted 'primary' (which
>> seems to be arbitrary and related to specific tools which could
>> probably deal with any limitation they have by taking the first
>> target mentioned as 'primary' by default).
>>
>> Have I misunderstood?
>>
>>>
>>> [5]- Def of Prerequisite: its las sentence is a repeat (said before).
>>
>> Agreed. Good catch
>>
>>>
>>> [6]- Def of "Tag":
>>> - remove the (s)
>>> - remove the references to the reader
>>> ("these tags provide you with..." --> "these tags provide an
>>> opportunity...")
>>> ("they enable you to group..." --> "they allow for grouping")
>>> Same for the "Variables" definition --> Variable.
>>
>> OK
>>
>>>
>>> --------------------------------
>>> Section 3.2:
>>>
>>> [7]- same as [3], for the names in the table.
>>
>> OK
>>
>>
>>>
>>> [8]- in the testAssertion formal def: paragraph before last: it seems to
>>> suggest that
>>> several prerequisites are OK ("... together or multiple prerequisites...
>>> A test assertion may have prerequisite(s)". Remove these allusions.
>>> Confusing as we clearly have just one Prereq.
>>
>> Well. I kind of agree but with reservations. In the markup we
>> have a policy that we combine prerequisite components into
>> one expression. In modeling terms though I think the distinction
>> with, say,
>>
>> TA(A) = 'pass' AND TA(B) = 'pass'
>>
>> between calling "TA(A) = 'pass'" one of two prerequisites here
>> and calling "TA(A) = 'pass' AND TA(B) = 'pass'" a single
>> prerequisite is so fine a distinction that I don't think we can
>> make using one or other of these a requirement. Some could
>> say that "TA(A) = 'pass' AND TA(B) = 'pass'" is a combination
>> of two prerequisites and that they could indeed be combined
>> using an expression, as here, or using some other construct
>> in the representation. I just wouldn't see it as the place of the
>> model spec to say whether prerequisites should always be
>> seen as one prerequisite combining the separate parts.
>>
>> Still, I'll have a look at the details of what changes would be
>> required in the text.
>>
>>>
>>> [9]- Formatting: each new construct that is introduced as : "Formal
>>> Definition:"
>>> is not highlighted enough: only the root constructs are, e.g.
>>> normativeSource.
>>> I wish its parts would also be highlighted in some way, e.g.:
>>> Formal Definition for refSourceItem:", or with a title, even if at same
>>> level as normativeSource (for refSourceItem, derivedSourceItem...)
>>
>> Agreed.
>>
>>>
>>> [10]- when introducing textSourceItem and derivedSourceItem: it is said they
>>> are "alternatives" to other options, suggesting exclusiveness.
>>> Make it clear they could be "an alternative - or a complement - to.."
>>
>> Agreed.
>>
>>
>>>
>>> [11]- derivedSourceItem: why does it have a complex structure like
>>> refSourceItem?
>>> Should be much simpler like textSourceItem.
>>
>>
>> I think we may need to discuss this a bit. I hadn't envisiaged
>> both a refSourceItem and a derivedSourceItem or both a
>> textSourceItem and a derivedSourceItem bing used for the
>> same requirement unless the requirement consisted of
>> several sources of different kinds. Therefore to properly
>> model a single source item it doesn't seem right to me to
>> use two distinct source item types - not unless they are in
>> fact two separate source items. So for this reason I thought
>> we would need the derivedSourceItem to be able to say what
>> source item(s) it is derived from, without having to combine
>> it with a refSourceItem. It therefore, I had thought, would
>> have the structures needed to make reference(s), as well as
>> the structure to add some derived text.
>>>
>>> [12]- definition of "interpretation":
>>> We could add: "It provides additional clues about how the Predicate (or
>>> Prereqisite)
>>> relates to the normative source."
>>
>> I'm OK with something like that
>>
>>>
>>> [13]- Target def: "The Target shall be the subject of the test assertion..."
>>> Because of [4] above, say rather: "The Target shall be the primary subject
>>> of
>>> the test assertion.."
>>
>> Again, as above, I'm not sure about this one
>>
>>>
>>> [14]- def of Variable:
>>> replace:
>>> "...using a notation such as $variable1"
>>> with:
>>> "...e.g. using a notation such as $variable1"
>>> Also, add that " a variable may also contain a logical expression, e.g. a
>>> subset
>>> of a Prrequisite or Predicate."
>>
>> Well, strictly speaking the 'notation' part would
>> be treated as normative but not the example so
>> to move the 'notation' into the example does
>> have the affect of making it vaguely informative.
>> Perhaps this is the intention. Perhaps it should
>> be removed altogether if it shouldn't be normative.
>> Some kind of notation is needed in our markup
>> to use a variable by name within an expression.
>> Do we not want to state this as a requirement?
>>
>>>
>>> [15]- def of Report:
>>> Replace:
>>> "the circumstances which shall be true for the report to be generated. It
>>> shall contain an expression
>>> which evaluates to true or false."
>>> with:
>>> "the circumstances in which this report item should be generated. It shall
>>> contain an expression
>>> which evaluates to true or false, or refer to such an expression (e.g. as
>>> contained in some variable) ."
>>
>> No longer relevant as we are removing 'report'
>>
>>>
>>> --------------------------------
>>> Section 3.3 (Semantics)
>>>
>>> [16]- replace:
>>> "As a test assertion has parts that can be evaluated over a Target instance
>>> (i.e. the prerequisite and the predicate),..."
>>> with:
>>> "As a test assertion has parts that can be evaluated over a Target instance
>>> (i.e. the prerequisite, the predicate, and possibly some variable containing
>>> expressions),..."
>>
>> OK (though I would think that resolving the variables would
>> be part of the interpretation of the predicate and prerequisite
>> and would happen before evaluation of the TA).
>>
>>>
>>> [17]- use bold font for the semantic outcomes ("Target not qualified", etc)
>>
>> Agreed
>>
>>>
>>> --------------------------------
>>> Section 4:
>>>
>>> [18]- as a gneral rule, there should be a short introductory sentence
>>> between the sub-Titles and the
>>> formal def of the construct they announce:
>>> E.g. below testAssertionSet and its formal def, add:
>>> "Test Asserions may be grouped using a testAssertionSet class."
>>> - Same for testAssertionRef: move up the sentence :
>>> "A test assertion set may refer to one or more test assertions by their test
>>> assertion identifiers rather than
>>> include the test assertions literally within the set."
>>> - Same for testAssertionResource:
>>> "testAssertionResource is used when test assertions are contained in another
>>> external document."
>>
>> OK
>>
>>>
>>> --------------------------------
>>> Section 5:
>>>
>>> [19]- Conformance clause:
>>> - in (2) and especially (3): should we replace "test assertion parts" with
>>> "test assertion constructs",
>>> because in section 4 these are not TA parts per say, but more generally
>>> higher level constructs as well.
>>
>> I agree
>>
>>> - Should we also consider a second kind of conformance target, beside
>>> "representations":
>>
>> As per last meeting, I'm not sure the model spec
>> should give conformance clauses about conformance to
>> all representation specs. I would leave that to the representation
>> spec writers. The users of a markup or other representation
>> might not even have access to this model spec's conformance clause.
>>
>> I do appreciate, however, that in some cases there may not
>> be a representation spec but here it would be difficult to claim
>> conformance anyway to the model (and maybe not important).
>>
>> I'm open to discussion though - maybe in view of any public
>> review comments.
>>
>>> By extension, instances of Test Assertions can be said conforming to this
>>> model, if:
>>> - if they use a "TA representation" that is itself conforming.
>>> - or even if they use a simple informal notation not defined by a formal
>>> representation, they must use this
>>> notation in a way that is unambiguously mapped to this model and its class
>>> system, e.g. respecting
>>> cardinalities and using unambiguous names.
>>> (I am thinking of the informal notation we introduce in the Guidelines, for
>>> examples...)
>>>
>>
>