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

[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=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
>>>>>
>>>>
>>>
>>
>