Mapping Services Facility › Map Source Definitions › Data Tagging › MDO Tags

MDO Tags

To differentiate between data items maintained internally in their local form, Mapping Services also requires that all components have a recognizable tag.

Because a tag value prefixes most components in the MDO local form, the MDO is a self-defining structure that allows, for example, an MDO to be stored and later retrieved while the data within remains separately identifiable even where the map might have altered slightly. As long as map maintenance does not change the relationship between tag values and the components they represent, maps can be extended and modified without affecting the ability to process an MDO defined under a previous map version.

Mapping Services ignores tag classes, and simply uses an integer value as a tag. However, the MDO tag numbers must be unique within a logical structure in the same way that component names must be unique within that structure. Hence, within any structure (such as a sequence or a set), all components must have unique names (enforced by ASN.1) and corresponding to each component a unique MDO tag number (enforced by Mapping Services).

These MDO tags can be set explicitly and independently of ASN.1, or can be generated by the compiler. However, the compiler can be directed to use the ASN.1 tag values as MDO tag values. This is likely to be the case where the map being developed has no requirement for BER encoding, hence all tag values are open to interpretation by Mapping Services only.

Note: By defining the tags explicitly in the source data, the user is afforded a greater level of protection against change. MDOs that are created using one version of the map can often continue to be compatible with higher versions of the map, even though new components are added. However, if the compiler generates the tags, this is unlikely to be the case.