A GDS that includes support for AliasNamesshall automatically aggregate all instances of AliasNameTypethat are available in any Serverthat has registered with the GDS. If the same AliasNameis registered from different Servers, the GDS shall combine the AliasNamewithin its Aliasstructure. The GDS shall add the ServerURIof the registered Serverinto its ServerArrayProperty. It shall provide a single merged tree list for any of the well-known AliasNameCategoryType Objectsdefined in 9.3(i.e. TagVariablesor Topics). The organization of the actual structure of the AliasNameCategoryTypehierarchy is specific to the GDS vendor and/or the configuration of the GDS, but all AliasNameCategoryTypeinstances shall be aggregated into the GDS. This hierarchy allows for a single instance of the AliasNameTypeto appear in more than one location in the tree. Figure B-9illustrates the process a GDS that supports AliasNameswould follow.


Figure B-9– Server Registration Process

The GDS shall subscribe for ModelChangeEventsform the Server, to ensure that any changes to the AliasNameswould be reflected in the GDS. [note: not all Serverswill support ModelChangeEvents, but AliasName Aggregating Servershall support ModelChangeEvents]. When the GDS receives a ModelChangeEventit 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 AliasNamesand it is important that an efficient storage of AliasNameis provided to allow for fast AliasNameresolution (FindAlias)]