The following table specifies and comments the correspondance between elements of CDF and MSRSW.DTD. It is given in the same sequence as [Calibration Data File Specification;2001-07-19;Jeff Kainz;Chapter 4.0;] .
 Hint
CDF covers one particular use case while ASAM-MCD-2MC 2.0 and MSRSW.DTD covers multiple use cases. Therefore sometimes elements (mostly wrappers) occur which appear to be superfluous. These elements were retained in oder to keep structural compliance.

Mapping CDF elements to ASAM-MCD-2MC 2.0
CDF-Element
ASAM-MCD-2MC 2.0
Comment
CAL-DATA
<MSRSW>
The root element
COMPANY-INFO
<LONG-NAME> in <COMPANY> within <PROJECT-DATA>
There is no direct correspondance. It appears that CDF uses it only for copyright purposes. Although an easier workaround may be possible, usage of a substructure of <PROJECT-DATA> is proposed
FILENAME
 
There is no direct correspondance. MSRSW.DTD allows to keep version and company specific filenames (<ENTITY-NAME> within <ADMIN-DATA>).
Since the use case is not fully clear, this feature is not taken over the the proposal made in this document.
CHANGE-HISTORY
<DOC-REVISIONS>
The MSRSW.DTD is more powerful and therefore somewhat more complex in case of change-history. In particular it supports multiple changes per revision.
CHANGE
<MODIFICATION>
 
USERNAME
<TEAM-MEMBER-REF>
If the instance also populates <COMPANY> with <TEAM-MEMBERS>, then using [ID]/[IDREF] is still possible. Otherwise Usage of ID/IDREF should be turned off.
DATE
<DATE>
 
TOOL
 
There is no direct correspondance. The exact usecase shall be worked out. MSRSW.DTD provides the following options:
 
<PRIVATE-CODE> in <ADMIN-DATA>
 
XML Comments
 
<SPECIAL-DATA>
NOTE in CHANGE
<REASON>
 
DATA-VERISION
<REVISION-LABEL>
This mainly refers to the version of the file, not the version of the data in the file which might be different and therefore be kept within <CS-HISTORY>.
<SW-CS-DATA-IDENTIFIER> within <SW-INSTANCE-TREE>
This must be worked out in greater detail depending on the intended use cases.
NOTE in CAL-DATA
<INTRODUCTION> in <MSRSW>
This represents the introduction not to the entire file.
CAL-LIST
<SW-INSTANCE-TREE>
This is somewhat more complex because MSRSW.DTD supports multiple systems (e.g. ECUs) within one file. For each of these systems multiple calibration data sets are possible (as intended with the multiple CAL-LISTs).
NAME
<SHORT-NAME>
Each object (calibration lists as well as calibration objects) has a unique name.
SYMBOLIC-FILE
 
There is no direct correspondance. Since CDF works on a physical level, it is even possible to work without such a symbolic file. In order to handle this there are multiple options (see 1.3.1. Options for SYMBOLIC-FILE and TARGET-IMAGE)
NOTE in CAL-LIST
<INTRODUCTION> in <SW-INSTANCE-SPEC>
Since MSRSW.DTD supports multiple systems within one file, this is an enhancement to the CDF requests.
<DESC> in <SW-INSTANCE-TREE>
This corresponds to the intention of CDF specification.
CAL-ITEM
<SW-INSTANCE>
Each calibration item is represented by an SW-INSTANCE. MSRSW.DTD itself provides more features (variant coding, object oriented desing, arrays, structures). Therefore the content models do not match one by one.
NAME in CAL-ITEM
<SHORT-NAME>
 
AXIS
<SW-AXIS-CONTS>
The attributes of AXIS in CDF correspond to child elemements in MSRSW.DTD such as <SW-UNIT-REF> <SW-AXIS-INDEX>
VALUE
<V> for numerical values
<VT> for string values
MSRSW.DTD puts each value in an element of its own. This makes it much easier to handle the file in XML-tools.
The format attribute is covered by using <V> respectively <VT>
ANNOTATION
 
in the CDF specification, the difference to NOTE is not really clear. If Note is a short description of the CAL-ITEM in general, then <DESC> witin <SW-INSTANCE-PROPS-VARIANT> is intended to be used.
NOTE within CAL-ITEM
<REMARK> within <SW-CS-HISTORY>