Re: [tag] Groups - Test Assertions Model (Changes PDF) (testassertionsmodel-draft-1-0-5-changes.pdf) uploaded

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

Yes, I think we have it covered regarding qualifying
what we mean by mandatory. We have some notes
to this effect under the section on the testAssertion
class:
"In a concrete test assertion representation, mandatory
parts could be absent provided that they are
implicitly defined somewhere else (i.e. that their
actual representation can be inferred, either from a
container structure like a “test assertion set” or from
other rules)."

Best regards

Steve
---
Stephen D Green




2010/1/27 Jacques R. Durand <JDurand@us.fujitsu.com>:
> Restoring 0..1 for all "contents" is OK for me - that could be the job of a "representation" or of its profiles to be more strict if needed.
>
> I think the question came up because on one hand we require the Predicate to be always present - implicitly or explicitly -, but we also make it look like it could be empty...
>
> But I guess the most important is to preserve consistency.
> Along this line we could argue that , as Predicate (and other parts) could be "implicit" and represented outside the TA, they do not have to be mandatory in the "testAssertion" class itself - so maybe we should reverse the 1..1 for "mandatory parts" to 0..1 as well. Because the model itself allows for Tas to be part of a TA set with "shared" parts that are already taken care of outside the TA.
>
> I am OK doing the above - though we need 1 sentence or 2 to explain that although these parts must be defined (somehow) for each TA, the TA model allows them to be absent or empty in the TA class because of some other options, including the "implicit" mechanism.
>
>
> -jacques
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
> Sent: Tuesday, January 26, 2010 12:37 PM
> To: Jacques R. Durand
> Cc: tag@lists.oasis-open.org
> Subject: Re: [tag] Groups - Test Assertions Model (Changes PDF) (testassertionsmodel-draft-1-0-5-changes.pdf) uploaded
>
> I really tend to think we should go back to (0..1) for each 'content' attribute. The fact is, XML by default allows content to be null or non-null So <a>b</b> or <a/> are usually both allowed for a particular markup (I have hardly ever seen a markup schema which allows a string which doesn't also allow null <a/>).
> Although we want the model to apply to more than just markup representations we are clearly wanting it to apply in particular to use of XML markup.
>
> So XML with some empty tags, eg
>
> <a>
>  <b>
>  <c>d</c>
>  <c/>
>  </b>
>  <b/>
> </a>
>
> is so often encountered in XML markup that it almost goes without saying that tools will have to support the <a/> and <b/> as well as the <b>c</b>. I can imagine it being a problem in some cases but it is very much on a par with any use of XML, so much so that I would say you wouldn't be using XML markup if you didn't expect to be able to cater for this null content. (Though I realise UBL is an example of at least one language which partly specifies against empty tags.)
>
> I do have one other correction I would like to make too which is to allow further associations to be added to the 'sourceDocument' (i.e. to add the same phrase we have elsewhere in many classes "Other associations may be added to the sourceDocument class."). Also there is one diagram where the title has gone over to the next page.
>
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/26 Jacques R. Durand <JDurand@us.fujitsu.com>:
>> Stephen:
>>
>> I reviewed the Model and the Guidelines.
>> I think they look fine - except for one thing in the Model:
>>
>> I have again some reservation on the cardinality of "content" in target:
>>
>> target {
>> content : string (1..1)
>> type : string (0..1)
>> schemeRef : string (0..1)
>> language : string (0..1)
>>
>> The fact is, given that the Target offers the possibility of
>> specifying a type, some test assertions will only - and rightfully -
>> specify only the type (and not the content).
>> In fact, that is something that Tamelizer will likely support in a
>> future upgrade...allows to "inherit" test assertions associated with a
>> more general target type (but no precise content), when deciding which
>> Tas must be applied to some concrete target instance of a given
>> sub-type.
>>
>>
>> Can't we just have:
>>
>> target {
>> content : string (0..1)
>> type : string (0..1)
>> ...}
>>
>> And explicitly state a rule: "in any target instance, either the
>> content or the type must be specified" ?
>> The conf clause should then state more precisely:
>> "(1) [a TA representation] shall contain all test assertion parts
>> defined in Section 3 and reproduce the related usage restrictions."
>>
>> This is an issue only for Target (it makes more sense to impose 1..1
>> to content in Predicate and Prerequisite)
>>
>> -jacques
>>
>>
>> -----Original Message-----
>> From: stephen.green@documentengineeringservices.com
>> [mailto:stephen.green@documentengineeringservices.com]
>> Sent: Tuesday, January 26, 2010 1:53 AM
>> To: tag@lists.oasis-open.org
>> Subject: [tag] Groups - Test Assertions Model (Changes PDF)
>> (testassertionsmodel-draft-1-0-5-changes.pdf) uploaded
>>
>> Draft showing changes since previous draft (part of a paragraph in the
>> specification of the 'target')
>>
>>  -- Stephen Green
>>
>> The document revision named Test Assertions Model (Changes PDF)
>> (testassertionsmodel-draft-1-0-5-changes.pdf) has been submitted by
>> Stephen Green to the OASIS Test Assertions Guidelines (TAG) TC
>> document repository.
>>  This document is revision #30 of testassertionsmodel-draft-0-1.odt.
>>
>> Document Description:
>> Test Assertions, Part 1 - Test Assertions Model Version 1.0
>>
>> View Document Details:
>> http://www.oasis-open.org/committees/document.php?document_id=36090
>>
>> Download Document:
>> http://www.oasis-open.org/committees/download.php/36090/testassertions
>> mo
>> del-draft-1-0-5-changes.pdf
>>
>> Revision:
>> This document is revision #30 of testassertionsmodel-draft-0-1.odt.
>> The document details page referenced above will show the complete
>> revision history.
>>
>>
>> PLEASE NOTE:  If the above links do not work for you, your email
>> application may be breaking the link into two pieces.  You may be able
>> to copy and paste the entire link address into the address field of
>> your web browser.
>>
>> -OASIS Open Administration
>>
>