Tag linking is a mechanism that allows entity definitions to include references to other entity definitions. This allows you to partially or entirely compose an entity definition using referenced entity definitions. This provides flexibility in defining entities and promotes the reuse of entity definitions. The externalizers resolve the references among the entity definitions and to build the corresponding tag structures in memory. The externalizers resolve these references immediately after they read the generic entity definition files when the toolkit initializes. This is why the tag structure in memory differs from the tag structure contained in the entity definition files.
Note Externalizers achieve tag linking through pointers (references) and, therefore, any change made in the source of the tag appears in the referenced tag.
For example, the generic data definition file has a tag named refData refId. The refId attribute of the refData tag identifies the data element tag that replaces the refData tag during tag linking. When tag linking occurs, the externalizer scans the tags in memory for a data tag that has an id attribute that matches the refId value. When the externalizer finds the tag, it replaces the refData tag with the tag. Here is a definition before tag linking occurs:
Note In this case the relative position of the reference and the source definition does not matter as the externalizer reads the entire file into memory before performing any tag linking. However, the relative position is critical for an inner reference because of how the externalizer resolves the references. For example, say that you have a set of definitions is in the following order:
This happens because the externalizer, to solve the references in the tag linking process, takes the definitions in the order in which it reads them. Therefore, when the externalizer processes kcoll1 containing a reference to coll2, it replaces the reference by the current definition of coll2, which still contains a reference that has not been resolved. To avoid this problem, the definitions for the referenced data must come comes before the reference (the refData tag.) The following example orders the definitions so that the externalizer can resolve all references properly:
In the previous examples, the refData tag has only one attribute and this attribute names the replacing tag. However, not all referencing tags are this basic. For example, the refService tag has additional attributes. If the service externalizer simply replaces the refService tag, the definition would lose the reference tag's alias and type attributes. Instead, the service externalizer places the referred as a subtag of the refService tag. In the following example, there are sets of definitions from three generic files. The sampleCtx context references the customerData keyed collection defined in the generic data definition file. The sampleCtx context also references the realCSClient service, which is defined in a third generic file, the generic Services definition file.
The externalizers dereferences tags using the reverse of same technique that created the tags in memory. For a list of the linkable tags provided with the toolkit, see Linkable tags.