RosterUpdate
RIXML 2.5 Element
An element that represents individual changes to publisher personnel rosters, enabling communication of additions, updates, or deletions of people and groups involved in research production
A roster update gives a publisher the ability to communicate changes to the groups of people playing various roles on its behalf in the investment research marketplace. The common case would be a financial services firm updating its roster of research analysts with aggregator partners.
Usage
Required child element of RosterUpdates with multiple instances allowed, each containing StatusInfo and choice of Organization, PersonGroup, PersonGroupMember, or Person elements
Business Context
Critical for maintaining current personnel information in research aggregation systems, particularly for tracking analyst coverage assignments and organizational changes at financial services firms
Specification Guide
Overview
RosterUpdate represents a single roster change notification within the RIXML roster-updates sidecar schema, communicating an addition, modification, or deletion affecting people, person groups, or organizations involved in research production. It is the granular unit of change inside the RosterUpdates container, enabling publishers to push targeted personnel and organizational updates to aggregators and consumers so that analyst coverage mappings and contact information remain accurate over time.
Usage
RosterUpdate appears as a repeating child of RosterUpdates; multiple instances are allowed so that a single sidecar message can carry several independent changes. Each instance pairs a StatusInfo block — which signals whether the change is an add, update, or delete via statusType — with exactly one of Organization, PersonGroup, PersonGroupMember, or Person as a choice, identifying the entity being changed. The optional rosterUpdateID attribute uniquely identifies the update so consumers can deduplicate, acknowledge, or audit individual changes; UUIDs are recommended for global uniqueness.
Rules
- SHOULDEach RosterUpdate should carry StatusInfo indicating the type of change (add, update, or delete) so that consumers can apply the update correctly.[RIXML Research Data Dictionary v2.5.1 p.135] [RIXML Research Data Dictionary v2.4 p.131]
- MUSTA RosterUpdate contains exactly one of Organization, PersonGroup, PersonGroupMember, or Person as a choice, identifying the entity being changed.[RIXML Research Data Dictionary v2.5.1 p.135] [RIXML Research Data Dictionary v2.4 p.131]
- SHOULDPublishers should populate rosterUpdateID (a UUID is recommended) so consumers can track applied updates and detect duplicates.[RIXML Research Data Dictionary v2.5.1 p.135]
Relationships
- child-ofRosterUpdates — RosterUpdate is a repeating child of the RosterUpdates container element in the roster-updates sidecar schema.
- requiresStatusInfo — RosterUpdate uses StatusInfo to indicate whether the update is an add, update, or delete operation.
- contains-choiceOrganization — RosterUpdate may carry an Organization as the subject of the change.
- contains-choicePersonGroup — RosterUpdate may carry a PersonGroup as the subject of the change.
- contains-choicePersonGroupMember — RosterUpdate may carry a PersonGroupMember as the subject of the change.
- contains-choicePerson — RosterUpdate may carry a Person as the subject of the change.
- identified-byRosterUpdate.rosterUpdateID — The optional rosterUpdateID attribute uniquely identifies an update, enabling tracking and deduplication by consumers; UUIDs are recommended.
Where It Fits
Canonical Path
Definition
| Type | RosterUpdateType |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
rosterUpdateIDstring |
This is to facilitate the unique identification of a particular individual roster update. Enables a consumer of this information to keep track of which updates have been applied to its database and which are duplicates. We recommend UUIDs to ensure uniqueness. optionalSince 2.5 |
Children
StatusInfo(complex)1..unbounded |
For statusType attribute, use: Published=Add, Revised=Update, Deleted=Delete. requiredSince 2.5 |
OrganizationOrganizationType1..1 |
requiredSince 2.5 |
PersonGroup(complex)1..1 |
requiredSince 2.5 |
PersonGroupMember(complex)1..1 |
requiredSince 2.5 |
PersonPersonType1..1 |
requiredSince 2.5 |
Example
<RosterUpdate>
<StatusInfo> ... </StatusInfo>
<Organization> ... </Organization>
<PersonGroup> ... </PersonGroup>
<PersonGroupMember> ... </PersonGroupMember>
<Person> ... </Person>
</RosterUpdate>Version History
Unchanged since introduction in RIXML 2.5
RosterUpdate is defined in the Roster Updates sidecar schema in RIXML 2.4 (data-dictionary-2.4, p.131) and continues unchanged in structure in 2.5 (data-dictionary-2.5.1, p.135), retaining the same child choice of Organization, PersonGroup, PersonGroupMember, or Person plus StatusInfo, and the optional rosterUpdateID attribute. Draft v3 taxonomy work proposes adding standardised role values that could be attached to roster updates as an optional attribute [RIXML v3 Taxonomy Review Summary: People and Organizations p.3]↗; this is exploratory and not part of the published 2.x schemas.
Business Rules
Universal Unique Identifiers (UUIDs) should be used for roster update identification to ensure uniqueness
Design Decisions
Unique identification for roster updates should preferably use UUIDs to ensure global uniqueness
Enables consumers to track which updates have been applied to their databases and identify duplicates
RIXML Research Data Dictionary v2.5.1, p.135
Semantic Relationships
Requires1 relationship
Roster updates must include status information to indicate whether the update is an add, update, or delete operation for tracking changes to research analyst rosters
RIXML Research Data Dictionary v2.5.1, p.135— RosterUpdate
Constrains1 relationship
The roster update identifier enables consumers to track which updates have been applied and identify duplicates, with UUIDs recommended for uniqueness
RIXML Research Data Dictionary v2.5.1, p.135— rosterUpdateID