RosterUpdates
RIXML 2.5 Element
A root element serving as the container for batched roster update transactions that communicate changes to analyst and personnel information. This sidecar schema element provides publishers with a standardized mechanism for distributing analyst roster modifications, including additions, updates, and deletions of personnel information to clients and aggregator partners.
RosterUpdates is the root tag for a batch of roster updates. 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
Used as the top-level element in roster update documents, containing multiple RosterUpdate child elements. Required when publishing analyst roster changes or personnel updates. Must include rosterUpdatesID, createDateTime, and language attributes.
Business Context
Essential for maintaining current analyst contact information and coverage assignments across research distribution networks. Enables publishers to systematically update client databases with personnel changes, ensuring accurate analyst attribution and contact information.
Specification Guide
Overview
RosterUpdates is the root element of the Roster Updates sidecar schema, a standalone document type used by research publishers to communicate batched changes to analyst and personnel rosters. It acts as a container for one or more RosterUpdate transactions that describe additions, modifications, or removals of Organization, PersonGroup, and Person records involved in research production and distribution (sources: data-dictionary-2.4 p.131, data-dictionary-2.5.1 p.135). The sidecar schema exists alongside the main Research document type so that publishers can keep buy-side clients and aggregator partners synchronised with current analyst contact information, coverage assignments, and organisational structures without embedding personnel data inside every research product.
Usage
Use RosterUpdates as the top-level (root) element of a standalone roster-update document. A document contains one or more RosterUpdate child elements, each representing an individual personnel or organisational change. Required attributes on the root element: - rosterUpdatesID — a unique identifier for the batch. - createDateTime — timestamp marking when the batch was assembled. - language — ISO 639-2/T language code for the textual content of the batch. Typical scenarios for publishing a RosterUpdates document include onboarding new analysts, recording departures, updating contact details, and reflecting coverage or role reassignments across the research staff (sources: data-dictionary-2.4 p.131, data-dictionary-2.5.1 p.135).
Relationships
- containsRosterUpdate — RosterUpdates contains one or more RosterUpdate child elements, each describing an individual roster change transaction.
- referencesOrganization — Roster changes carried inside RosterUpdates typically describe modifications to Organization records that participate in research production.
- referencesPerson — Roster changes carried inside RosterUpdates commonly describe additions, updates, or removals of Person records (analysts and other personnel).
- referencesPersonGroup — RosterUpdates may carry updates to PersonGroup records that represent teams or other groupings of research personnel.
- qualified-bySpecialtyEnum — In the v3 draft, SpecialtyEnum qualifies RosterUpdates, allowing organisations to self-identify areas of firm specialisation.
Where It Fits
Canonical Path
Children
Definition
| Type | RosterUpdatesType |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
rosterUpdatesIDstring |
This is to facilitate the unique identification of a particular batch of roster updates. Enables a consumer of this information to keep track of which batches have been applied to its database and which are duplicates. We recommend UUIDs to ensure uniqueness. requiredSince 2.5 |
createDateTimedateTime |
This marks the date/time at which this research bundle was formed. It is expressed using ISO 8601 as refined by the World Wide Web Consortium's note http://www.w3.org/TR/NOTE-datetime. In addition, RIXML requires the use of Zulu time or Z-time (GMT +/- n hours:minute:seconds). All times are absolute and easier to compute, rather than using a relative (i.e. 08:30 +5) time. requiredSince 2.1 |
Indicates the language of the RIXML document -- i.e. the language of the publisher-supplied tag values contained in the RIXML-based XML file for this research item. Described using the ISO 639-2/T Code. requiredSince 2.1 |
Children
RosterUpdateRosterUpdateType1..unbounded |
requiredSince 2.5 |
Example
<RosterUpdates rosterUpdatesID="2024-01-15T09:30:00Z"
createDateTime="2024-01-15T09:30:00Z"
language="eng">
<RosterUpdate> ... </RosterUpdate>
</RosterUpdates>Version History
Unchanged since introduction in RIXML 2.5
RosterUpdates is part of the Roster Updates sidecar schema documented in RIXML 2.4 (p.131) and carried forward in 2.5 / 2.5.1 (p.135), where it serves as the root element for batched analyst roster changes. The element was introduced to give publishers a standardised, separate channel for personnel updates distinct from the main research document. In the v3 draft, SpecialtyEnum is extended to qualify RosterUpdates so that firms can self-identify specialisation areas alongside roster information [v3-enumlist-set5-subject-specialty p.1].
Business Rules
DateTime values must be expressed using ISO 8601 format as refined by the W3C specification and must use Zulu time (GMT with timezone offset) rather than relative time representations
Language codes must be specified using the ISO 639-2/T standard format
RosterUpdatesID must be used to uniquely identify roster update batches and UUIDs are recommended for uniqueness
Design Decisions
DateTime attributes must use absolute time with Zulu time format rather than relative time representations
Absolute times are easier to compute and process compared to relative time formats like 08:30 +5
RIXML Research Data Dictionary v2.5.1, p.135
Language specification must use ISO 639-2/T three-letter language codes
Standardizes language identification across all RIXML documents for consistent processing
RIXML Research Data Dictionary v2.5.1, p.135
Created RosterUpdates sidecar schema element as root tag for analyst roster management
To provide publishers with a standardized method for communicating analyst roster changes to clients and aggregator partners, leveraging existing RIXML schema elements
RIXML Research Data Dictionary v2.5.1, p.135
Made rosterUpdatesID attribute required with String type for batch identification
To enable unique identification of roster update batches, allowing consumers to track which batches have been processed and avoid duplicates, with UUID recommendation for uniqueness
RIXML Research Data Dictionary v2.5.1, p.135