Share via

3.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to explain how the protocol behaves. This specification does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior described in this specification.

The automation server needs to maintain a direct and consistent mapping for the DISPIDs that it recognizes for specific name requests. This mapping is permanent if, and only if, the method definition in the IDL file is marked with the id attribute (as specified in section 2.2.49.5) or if the server documents the mapping in the component documentation. If the preceding conditions are not satisfied, the automation server MAY<53> generate the mapping on the fly, but it maintains it for the extent of its own lifetime.

The automation server maintains a dispatch mapping table that contains a list of mapping entries for each supported locale ID. Automation clients calling servers that do not have their DISPIDs specified in the IDL and that also do not have their DISPIDs specified in the server documentation cannot assume that the mapping is permanent and always query for the current mapping.

Each mapping entry contains:

  • A list of names that identify the method or property and the named parameters that the server supports for it.

  • A corresponding list of DISPIDs.

Note The preceding conceptual data can be implemented by using a variety of techniques. Any data structure that stores this conceptual data can be used in the implementation.