Errata exists for this version of the document.

A GDS that includes support for AliasNames shall automatically aggregate all instances of AliasNameType that are available in any Server that has registered with the GDS. If the same AliasName is registered from different Servers, the GDS shall combine the AliasName within its Alias structure. The GDS shall add the ServerURI of the registered Server into its ServerArray Property. It shall provide a single merged tree list for any of the well-known AliasNameCategoryType Objects defined in 9.3 (i.e. TagVariables or Topics). The organization of the actual structure of the AliasNameCategoryType hierarchy is specific to the GDS vendor and/or the configuration of the GDS, but all AliasNameCategoryType instances shall be aggregated into the GDS. This hierarchy allows for a single instance of the AliasNameType to appear in more than one location in the tree. Figure B-9 illustrates the process a GDS that supports AliasNames would follow.

Figure B-9 - Server Registration Process

The GDS shall subscribe for ModelChangeEvents form the Server, to ensure that any changes to the AliasNames would be reflected in the GDS. [note: not all Servers will support ModelChangeEvents, but AliasName Aggregating Server shall support ModelChangeEvents]. When the GDS receives a ModelChangeEvent it shall update as needed and generate a ModelChangeEvent for its Clients - in essence the original event is forwarded to listening Clients.

[Note: a GDS may encounter a large list of AliasNames and it is important that an efficient storage of AliasName is provided to allow for fast AliasName resolution (FindAlias)]