This routine compares the catalog with a reference catalog files and generates an updated version attributes for incremental data exchange (see 1.2. Incremental data exchange) are populated. The basic principles are:
 
the result is a combination of both catalogs, esp. the <ablock>s of both catalogs appear in order to show the now unused objects.
 
the sequence of the objects is not taken into account when comparing the catalogs.
 
the <fields> are not taken into account when comparing the catalogs since there is no mean to handle the results.
 
The following strategy can be used to determine the [upd] attribute.

NEW
The object is newly introduced in the system. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).

Detect
Check for all <ablock>s in the catalog: There is no <ablock> in reference catalog with the same [name] attribute.
referenced objects
NEW, MOVED, REUSED

REUSED
The object was introduced in the system at former time but like NEW it is not in the reference catalog. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).

Detect
Check for all <ablock>s in the catalog: There is no <ablock> in reference catalog with the same [name] attribute.
referenced objects
REUSED, MOVED, CHANGED

UNUSED
The object is no longer used. The <ablock> is there in order to indicate, that the object can be removed in the configuration on the receiver's site. The <ablock> does not reference anything within the actual catalog.

Detect
Check for all <ablock>s in the reference catalog: There is no <ablock> in the catalog with the same [name] attribute. For the result, copy the <ablock> from the reference catalog, populate [upd] and drop all contents execpt <metadata>.
referenced objects
no referenced objects

UNCHANGED
The object is unchanged. Therefore it must already be available on the receiver's site. Therefore it is possible to omit the file itself.

Detect
Check for all <ablock>s in the catalog: The same <ablock> appears with the same version information in the reference catalog.
referenced objects
UNCHANGED

CHANGED
The object is changed. Therefore the contents file must be there (in particular, an <file> element) must occur within <ablock>.

Detect
Check for all <ablock>s in the catalog: The same <ablock> appears in the reference catalog but in another version.
referenced objects
CHANGED, UNCHANGED, REUSED, UNUSED, MOVED

MOVED
The object is unchanged but in different Groups. Therefore it must already be available on the receiver's site. Therefore it is possible to omit the file itself.
The object is changed and in different Groups. In tis case it will be changed.

Detect
Check for all <ablock>s in the catalog: The same <ablock> appears with the same version information in the reference catalog but was referenced from different <ablock>.
referenced objects
MOVED

The following hints apply:
 
The simple approach described here requires, that the name of objects is globally unique and that no two revisions of such an object appear simulatneously in the catalog. If this is not the case, much more complicated algorithms are required.
 
If synchroneous versioning applies (using multiple <cri> elements), then obvously the revsion info of one particular company must be taken into account. The company is given as a runtime argument of the procedure.
It could also be determined by a runtime argument, if the revision info of the <metadata> or the revision info in <ablock> is used.
 
<ablocks> without revision information shall be flagged as errors.