RE: target cardinality

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Stephen:

Agree we don't need a special rule for enforcing that the target element is non-empty.
Reason is based on my previous email.


-jacques

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Tuesday, January 26, 2010 1:00 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

Regarding 'target', it is clear that many of our elements would happily allow an XML attribute to be used instead of element content. It would always, unless there was some reason to disallow it (which I don't think we have in any case), be OK to write

<a b='c'/>

just as much as to write

<a>e</>

I don't think we need a special rule to cover this, especially in the model. If we just make all content (0..1) then we do not need to treat the target as a special case. After all it would be quite legitimate for us to specify the markup such that the was an actual attribute called 'content' and that the content of the target element was what we used to represent the 'type'.
We would just need some way to make it clear that 'type' was represented as the element content. In our case we have not chosen to do this but there is still nothing in the model itself to say that the target cannot be empty with the data going into the 'type' attribute. This is something the markup would have to specify, not the model, think. In other words, just because the markup allows a string inside target <target>...</target> it doesn't mean a given test assertion using the markup has to put some data in it. Maybe a profile could say that the 'type'
attribute is the main place to put target data and the target element content is not to be used. That doesn't seem to definitely violate the model, as far as I can say for sure. But this I think applies just as much to any other part of a TA, not just the target so making every class's 'content' attribute (0..1) would seem to me to cater for it. Any reason, for example, why the same doesn't apply to the 'level' attribute of the prescription element. The prescription element allows content beside the 'level' attribute but I see no harm in a profile saying the level has to be used and not the content of the prescription element. It seems sensible to put any restrictions on these usages of the representation resulting from the model in the spec of the representation and not into the model spec.


Best regards

Steve
---
Stephen D Green




2010/1/26 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/testassertion
>> smo
>> 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
>>
>