RE: target "options"

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

 Stephen:

I am for option 2.
I'd say we keep "type" because it has a significant meaning in our TA model, that is different from "content". In our Guidelines (4.11), we give best practices on how to make proper use of target types (categories) and relationsships between types.

-jacques

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

My preferred solution:

1. drop 'type' from the model (the markup keeps it)

2. make the content optional (0..1) in the model (I'd prefer it always optional except for prerequisite and predicate perhaps)

3. Let the Tamelizer profile specify that where type is used the target does not have to have content

4. Ensure that doing 3. does not break conformance

Best regards

Steve
---
Stephen D Green




2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
> All this considered it might be that the way we specify the semantics 
> of the target and the type attribute of target it is necessary to make 
> it a choice of one or the other but that seems to be driven too much 
> by one implementation and not enough by having clear semantics for the 
> target and its type attribute.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>> If on the other hand 'type' has separate semantics from target's 
>> content then maybe it is debatable whether to allow a profile to 
>> deprecate target content and emphasise the use of the type attribute 
>> instead. Really it has to allow both with the proviso that 1) type is 
>> mandated and 2) if the target element itself is otherwise empty then 
>> the value defaults to that of the type attribute. This rule would 
>> seem to me to make it comply with both markup and model. I guess it 
>> would be an obvious rule to have in such a profile anyway but I would 
>> think it would be necessary to have the profile conform to both the 
>> markup and, of necessity for the latter(?), the model.
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>>> Maybe we should remove target's 'type' from the model if we are not 
>>> clear on its semantics. Not sure what to do about the markup though. 
>>> Are you saying the 'type' is actually the place in the markup for 
>>> the meaningful target content and that it does not have semantics 
>>> distinct from the target content?
>>> If so we should either remove it in favour of the target element 
>>> content or make the target element empty (no string allowed).
>>> One or the other and not both. Interestingly this same problem 
>>> applies, with a variation, to the prescription level: we use a code 
>>> in the 'level' attribute to contain the meaningful content and use 
>>> the element content as a kind of description/note.
>>> That now seems a bit spurious. At least the model could maybe 
>>> distibguish the two a bit better by perhaps dropping the level as an 
>>> attribute or keeping level and removing the content and adding an 
>>> attribute for a description. I'm not sure though.
>>>
>>> Best regards
>>>
>>> Steve
>>> ---
>>> Stephen D Green
>>>
>>>
>>>
>>>
>>> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>>>> Regarding a profile saying that target should always be null and 
>>>> the 'type' attribute of the representation should always be used 
>>>> for the target content - I would think that might cause some 
>>>> interoperability issues.
>>>> I do have a few reservations about whether it complies with the 
>>>> model spec - its semantics and the rule that there must be obvious 
>>>> mapping between representation and specified model. To map the 
>>>> target content to the type attribute would, if done, seem to pose a 
>>>> problem with claiming conformance since it seems
>>>>
>>>> 1) the type attribute in the XML should definitely map to the type 
>>>> attribute in the model. If 'type' exists in the XML representation 
>>>> of target then there is clearly only one thing it would map to in 
>>>> the model - the type attribute there (not the content of the target 
>>>> instead).
>>>>
>>>> 2) the semantics and the section on TA parts seem to me to rule 
>>>> that target MUST have content and that the content MUST be used 
>>>> according to the semantics of the TA (although I still am not sure 
>>>> we have specified what the role of the target - its content - is in 
>>>> the semantics of the TA since it does not seem clear what it's 
>>>> affect has on the outcome).
>>>>
>>>> All this does show me we could do with tightening up the model spec 
>>>> a fair bit.
>>>>
>>>> Best regards
>>>>
>>>> Steve
>>>> ---
>>>> Stephen D Green
>>>>
>>>>
>>>>
>>>>
>>>> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>>>>> 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=36
>>>>>>> 090
>>>>>>>
>>>>>>> Download Document:
>>>>>>> http://www.oasis-open.org/committees/download.php/36090/testasse
>>>>>>> rtionsmo
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>