Re: [tag] General comments on the new split

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