Versions Compared

Version Old Version 11 New Version 12
Changes made by

WILSON Scott

WILSON Scott

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Different types of traces


Note
  • Can we survive with just using these names that are inspired by the words in the spec?
  • Can we merge the two types of "concept" traces into one name?
RequirementTrace requiredTrace nameDefinition
SWIM-INFO-016 Mapping of information conceptsrequires one concept trace"information concept" tracetrace from the information concept in the information definition to the AIRM concept that has an equivalent or wider meaning
SWIM-INFO-017 Mapping of data concepts

requires one concept trace and one data type trace

  1. "data concept" trace
  2. "data type" trace
  1. trace from the data concept in the information definition to the AIRM concept that has an equivalent or wider meaning
  2. trace to the data type in the AIRM that has an equivalent or wider meaning
SWIM-INFO-018 Additional traces to clarify the mappingallows any number of additional clarifying traces"additional" tracetrace to an AIRM concept to fully describe the narrowing of the concept being mapped

...

Trace nameSourceTarget
"information concept" traceLikely sources: information exchange requirements

Best place to start: Conceptual Model.

If not found there, use Contextual Model or Logical Model

  1. "data concept" trace
  2. "data type" trace
Likely sources: service message

Best place to start: Logical Model.

If not found there, use Contextual Model or Conceptual Model for the "data concept" trace
"additional" tracesource depends on the trace being clarified

Should be in the same model as the trace being qualified.

Info

The Interoperability Architecture provides good advice. Basically, trace to the adjacent box by default.

Reading order of traces

General reading order is:

...

How should the different traces be represented in the XSD examples we use?


Trace nameElement nameAttribute
"information concept" trace<informationConceptTrace><trace keyword="informationConceptTrace>
  1. "data concept" trace
  2. "data type" trace

<dataConceptTrace>

<dataTypeTrace>

<trace keyword="dataConceptTrace>

<trace keyword="dataTypeTrace>

"additional" trace


<additionalTrace>

<trace keyword="additionalTrace>

Info

If this is a best practice, the attribute option is probably preferable - the attribute can be optional and the name of the element is always <trace>

Full example

If we apply all of this:

Code Block
languagexml
<xs:annotation>
  <xs:documentation>
    <semanticCorrespondence>
      <mapping note="loss of info because of legacy">
        <informationConceptTrace degree="specialised">-AIRM unique identifier-</informationConceptTrace>
        <additionalTrace>-AIRM unique identifier-</additionalTrace>
      </mapping>
    </semanticCorrespondence>
  </xs:documentation>
</xs:annotation>

or:

Code Block
languagexml
<xs:annotation>
  <xs:documentation>
    <semanticCorrespondence>
      <mapping note="loss of info because of legacy">
        <trace type="informationConceptTrace" degree="specialised">-AIRM unique identifier-</informationConceptTrace>
        <trace type="additionalTrace">-AIRM unique identifier-</additionalTrace>
      </mapping>
    </semanticCorrespondence>
  </xs:documentation>
</xs:annotation>

...