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

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

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/testassertionsmo
> 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
>