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

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

I'll do the following in the model

1. drop type from target
2. make target content (0..1)

Note: there is the general case that any class which
can be extended could be given a new attribute which, in
some representation, actually gets used instead of
the content, as with the 'type' attribute of the target. And
this attribute might be more appropriate for the representation
to make mandatory. So hardly any classes can have
mandatory content. However, for predicate and prerequisite
I'd say that they can be 1..1 for clarity and interoperability.

3. make all content (0..1) except predicate and prerequisite
  (and shared equivalents)


Best regards

Steve
---
Stephen D Green




2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
> So if we drop 'type' from 'target' in the model
> (that means Tamelizer can map target/@type to
> the target content of the model) then type is
> there in the markup but not well specified so it
> plays no key role in the markup semantics but
> in the Tamelizer profile you'd be free to specify
> a rule about @type even to the extent of having
> it replace the use of the target element content.
> because the markup doesn't prevent this you
> are OK and because the model lets you map
> type (sometimes?) to target content you are OK.
> Then even if the model said target content was
> (1..1) your profile would be OK because it would
> have type mapped to target content at model level.
> The only problem, I think, seems to be that if
> the model says target content is (1..1) then the
> markup doesn't enforce that since it allows the
> content to be empty (as XML usually does). So
> for that reason I'd also tend to go back to (0..1)
> as it seems to be less likely to cause ambiguity
> in what conformance requires in the markup.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>> It would be nice if for every part of a TA we
>> made it clear (to ourselves first, then the
>> specs) which precise bit of that part's structure
>> was the 'active ingredient' in the overall role
>> it plays in the TA. For prescription it is clearly,
>> at first sight, the level attribute. For predicate
>> and prerequisite it is the content. But it gets
>> more complicated when you think about the
>> shared predicates and prerequisites so an
>> inherited content combined with an algorithm
>> based on the value of any 'conflict' attributes
>> provides the real meaningful value of the part.
>> That applies to every part. That considered,
>> the target ought to be like predicate and
>> prerequisite, I think; it's content should be the
>> value it primarily has in a TA. Normative source
>> is complex because it can either be the content
>> or the content of the combination of the source
>> items. Ugh! It all gets rather messy doesn't it?
>> So really I'd want to simplify target by saying the
>> type provides supplementary data only and the
>> type is not important enough to be intrinsic to
>> the primary semantics of the TA as a whole. If
>> you have a target which uses 'type' I would want
>> to say it has to either also have content or there
>> has to be a rule to say that if the content is blank
>> the target has to default to the value of type. But
>> that rule ought to be in the markup or a profile
>> of the markup (like Tamelizer's). In the model it
>> should be that target has to have content somehow.
>> I'd say that content could come either from the
>> class itself or from the TA set and a shared target.
>> So the content can be (0..1) to allow for the latter.
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2010/1/26 Stephen Green <stephen.green@documentengineeringservices.com>:
>>> 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=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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>