Re: [tag] General comments on the new split

[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

Test Assertion Model.jpg