RIXML Documentation

InstantMessenger

RIXML 2.5 Element

Required

Instant messaging contact information supporting various IM protocols. Contains required type attribute (InstantMessengerTypeEnum for AIM, ICQ, MSN, SMS, Yahoo, etc.) and optional publisherDefinedValue for specifying other IM systems not in the standard enumeration.

Usage

Optional element within ContactInfo that can appear multiple times. Type attribute is mandatory to specify the IM protocol. Use publisherDefinedValue when the IM system is not covered by standard enumeration values.

Business Context

Provides real-time communication channels for research distribution and client interaction, supporting immediate consultation capabilities and modern digital communication preferences in financial services.

Source:data-dictionary-2.5.1
Schema:RIXML-Common-2_5.xsd:1151

Specification Guide

Overview

InstantMessenger captures an instant-messaging contact address for a person or organization, qualified by the messaging protocol in use. It lives inside ContactInfo alongside other contact channels such as Phone, Email, Address and Website, providing a real-time communication option for research producers and consumers (sources: data-dictionary-2.4 p.32, user-guide-2.3 p.21, data-dictionary-2.5.1 p.34). The element's content is the IM handle/address itself, while the type attribute (drawn from InstantMessengerTypeEnum) identifies the protocol — historically AIM, ICQ, MSN, SMS, and Yahoo. From RIXML 2.1 onward, a PublisherDefined enum value plus an optional publisherDefinedValue attribute allow capture of messaging systems not present in the standard enumeration (sources: release-notes-2.1 p.4, user-guide-2.1 p.21).

Usage

InstantMessenger is an optional child of ContactInfo and may appear multiple times so that a single contact can list handles across several IM platforms (sources: data-dictionary-2.4 p.32, user-guide-2.2 p.21, data-dictionary-2.5.1 p.34). Typical usage: - Provide the IM address as the element's text content. - Always set type to identify the protocol from InstantMessengerTypeEnum. - When the protocol is not in the standard enumeration, set type to PublisherDefined and supply the system's name via publisherDefinedValue [release-notes-2.1 p.4]. The element is intended for real-time/urgent communication scenarios — for example, time-sensitive research alerts, event coordination, and direct analyst–client dialogue — complementing the more durable channels in ContactInfo (sources: user-guide-2.1 p.21, user-guide-2.3 p.21).

Rules

Relationships

Where It Fits

Canonical Path

Definition

Type
Namespacehttp://www.rixml.org/2017/9/RIXML
Min Occurs1
Max Occurs1
Content ModelText content (string)

Attributes

typeInstantMessengerTypeEnum

Indicates the Instant Messenger protocol type -- i.e. AIM, ICQ, MSN, SMS, Yahoo, etc.

required

For specifying other IM systems.

optionalSince 2.1

Children

Contains text content (type: string)

This element's value is its text content. Attributes provide additional context.

Example

<InstantMessenger type="Value">ABC-123</InstantMessenger>

Version History

Unchanged since introduction in RIXML 2.1

- 2.0 — Element introduced as an optional, repeatable child of ContactInfo, with a required type from InstantMessengerTypeEnum supporting AIM, ICQ, MSN, SMS, and Yahoo [data-dictionary-interactions-2.0 p.21]. - 2.1InstantMessengerTypeEnum extended with a PublisherDefined value, and a new optional publisherDefinedValue attribute added to identify custom or emerging IM systems not covered by the standard list (sources: release-notes-2.1 p.4, user-guide-2.1 p.21). - 2.2 – 2.5.1 — Definition and usage unchanged; the element remains an optional, repeatable child of ContactInfo with the same attribute model (sources: user-guide-2.2 p.21, user-guide-2.3 p.21, data-dictionary-2.4 p.32, data-dictionary-2.5.1 p.34). - 3.0 (draft)InstantMessenger has been removed from the contact-information structure. Working-group discussions cite obsolete protocols and improvements to the surrounding contact tagsets as the rationale; alternatives considered included retaining the element in updated form or replacing it with modern messaging alternatives, both of which were rejected (sources: data-dictionary-v3-draft p.27, meeting-2025-01 p.35, meeting-2025-06 p.22, meeting-2024-winter p.22).

Related Elements