Re: [tag] General comments on the new split

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

I attach a sample of how I'd propose to represent the model in the
Part 1 spec (diagrams not included).

Best regards
---
Stephen D Green




2009/11/21 Stephen Green <stephen.green@documentengineeringservices.com>:
> So the test assertion model could be represented like this
>
> "
> testAssertion
> -------------------
>
> Representation:
>
> class: testAssertion
> associations{
> -> testAssertion_type (1..1)
> }
>
> class: testAssertion_type
> attributes{
>  id : string (0..1)
>  lg : string (0..1)
>  schemaVersionId : string (0..1)
>  ...
> }
> operations{
>  normativeSource : normativeSource_type
>  target : target_type
>  prerequisite : prerequisite_type
>  predicate : predicate_type
>  prescription : prescription_type
>  description : description_type
>  tag : tag_type
>  var : var_type
>  report : report_type
>  ...
> }
> associations{
>  -> normativeSource_type (0..1)
>  -> target_type (0..1)
>  -> prerequisite_type (0..1)
>  -> predicate_type (0..1)
>  -> prescription_type (0..1)
>  -> description_type (0..1)
>  -> tag_type (0..*)
>  -> var_type (0..*)
>  -> report_type (0..*)
>  ...
> }
>
> Other attributes, operations and associations may be added.
>
> [... semantic specifications ...]
> "
>
>
>
>
> Best regards
> ---
> Stephen D Green
>
>
>
>
> 2009/11/21 Stephen Green <stephen.green@documentengineeringservices.com>:
>> Jacques,
>>
>> I agree with these comments. It would mean we need a means
>> of representing the model in a neutral way (i.e. without alluding
>> to the XML).
>>
>> Maybe we could do this by very simply (I favour simplicity here)
>> removing 'angle brackets' from the representation in the markup
>> spec. We need to agree an appropriate mapping of datatypes,
>> e.g. normalizedString to string
>> When the element is global (e.g. testAssertion) it can be
>> represented as an association to a class for the complexType
>>
>> Replacing XML angle brackets with curly brackets {...} and
>> replacing the 'Content' with "operations{one(), two(), ...}"
>> and using an association to link an element in the markup
>> with its complexType - representing the global elements
>> as classes which are associated with other classes which
>> represent the corresponding complexTypes; something like
>>
>> <example
>>    name: xsd:normalizedString
>>    id: xsd:normalizedString>
>>  Content: one ?, two +, three *
>> </example>
>>
>> if the element 'example' is global, becomes something like:
>>
>>
>> class: example
>> associations: {
>>   example_type
>> }
>>
>> class: example_type
>> attributes: {
>>    name : string
>>    id : string
>> }
>> operations: {
>>   one : one_type
>>   two : two_type
>>   three : three_type
>> }
>> associations: {
>>   one_type, 0..1
>>   two_type, 1..*
>>   three_type, 0..*
>> }
>>
>> I'm not sure this does all we need, e.g. we need a way to distinguish
>> a sequence from a choice or group.
>>
>> E.g. how do we represent the following?
>>
>> group:
>> <example
>>    name: xsd:normalizedString
>>    id: xsd:normalizedString>
>>  Content: one ?, (two, three) *
>> </example>
>>
>> choice:
>> <example
>>    name: xsd:normalizedString
>>    id: xsd:normalizedString>
>>  Content: one ?, (two | three) *
>> </example>
>>
>> Or do we perhaps not need the model to include such detail?
>>
>> Perhaps we only need to represent the attached model diagram
>> and include the semantics we have in the markup spec.
>>
>> It would be nice if there were a standard way to do this
>> but as with the markup we may just need to decide and
>> declare/describe our own means of representation.
>>
>>
>> Best regards
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2009/11/21 Jacques R. Durand <JDurand@us.fujitsu.com>:
>>> Test Assertions Guidelines: (1.0.8.7)
>>> ----------------------------------------
>>>
>>> - appears to me as almost ready to go.
>>>
>>> - need to refer explicitly to the new "TA Model" spec, both in the Intro and
>>> in the (dummy) Conformance section.
>>>
>>> - we might consider reformatting Appendix B so that instead of just
>>> repeating the TAs from main body, it formats them using the mark-up.
>>>
>>> Test Assertions Model: (0.2)
>>> ----------------------------------------
>>>
>>> - probably the one that needs more work:
>>>
>>> - it appears to me that anything that is defined currently in the TA mark-up
>>> and that  actually can describe the TA model itself independently from XML
>>> representation, should now be in this doc.
>>> (I.e. we currently have some semantic explanation in the mark-up that
>>> actually apply to the model itself, regardless of its representation.)
>>>
>>> - Fig 1 ("roles of TA in 2 examples of workflow") has its place in the
>>> Guidelines but probably not in this more formal reference doc?
>>>
>>> - The general diagram in Appendix A could be split into several diags that
>>> represent logical clusters, e.g. "testAssertion_set",
>>>  "shared", "normativeSource_type". Would solve the editorial display issue
>>> too...
>>>
>>> - The Glossary could be merged into the definitions in 3.1 / 3.2 to make a
>>> more formal description (the definitions split in the Guidelines makes sense
>>> because we wanted just "intuitive" defs at beginning, and a more complete
>>> Glossary at the end. But in a ref model as here, split not justified).
>>>
>>> - Seection 2: could be renamed like "Definitions and Rationale", then we
>>> start right away with 2.2 content, then at the end we blend-in 2.1
>>> alleviated content , explaining the benefits.
>>>
>>> - Section 3 could be just: "Test Assertion"
>>> then 3.1 "Test Assertion Structure and Elements", starting with the diagram,
>>> then would list the detail of each element along the format of the current
>>> mark-up doc (except no XML...)
>>> then 3.2 "Semantics" would be current section 4.
>>>
>>> - Section 4 could be "Test Assertion Set", then go into details of the TA
>>> set model (along format used in the mark-up doc)
>>>
>>>
>>>
>>> Test Assertions Mark-up: (0.9.7)
>>> ----------------------------------------
>>>
>>> - Overall content-complete, but now in need to undergo a "semantic
>>> reduction" by migrating most semantic definitions and bits that are not
>>> proper to the markup itself , back into the TA model. Needs then to refer to
>>> the new TA model. A bit of redundancy with TA model is probably acceptable
>>> though.
>>>
>>> -jacques
>>
>

testassertionmodel-sample-spec.odt