CoverageUpdates
RIXML 2.5 Element
The root element for batches of coverage updates that enables publishers to communicate changes to their coverage universe using existing RIXML elements in a specialized structure
CoverageUpdates is the root tag for a batch of coverage updates. A coverage update gives a publisher the ability to communicate changes to its coverage universe. The common case would be a financial services firm updating the list of companies covered by a particular analyst.
Usage
Top-level element of the Coverage Updates sidecar schema containing required attributes coverageUpdatesID, createDateTime, and language, with multiple CoverageUpdate child elements
Business Context
Provides standardized mechanism for financial services firms to notify clients and aggregators about changes in analyst coverage assignments and research focus areas
Specification Guide
Overview
CoverageUpdates is the root element of the RIXML Coverage Updates sidecar schema, used by publishers to communicate batch changes to their research coverage universe. It acts as a top-level container that groups one or more CoverageUpdate entries, each describing a modification to the relationships between covering entities (analysts, teams) and covered entities (issuers, securities, sectors, regions, themes). The element exists alongside the main RIXML schema to provide a standardised mechanism for notifying clients and aggregator partners about who covers what, supporting compliance, research routing, and client-relationship workflows (sources: data-dictionary-2.4 p.132, data-dictionary-2.5.1 p.136).
Usage
Use CoverageUpdates as the document root when transmitting a batch of coverage changes; it is not embedded inside a Research document. Three attributes are required on the root: coverageUpdatesID (a unique batch identifier, with UUIDs recommended), createDateTime (an ISO 8601 timestamp, recommended in Zulu time), and language (an ISO 639-2/T language code). The root then contains one or more CoverageUpdate children, each of which typically holds a CoveragePairing linking CoveringEntities to CoveredEntities [RIXML Research Data Dictionary v2.5.1 p.136].
The sidecar schema is distributed as a separate XSD file (e.g. RIXML-CoverageUpdates-2_5.xsd from RIXML v2.5) and should be deployed alongside the main RIXML schema [RIXML Quarterly Update 2017 Q3 p.8]↗.
Rules
- MUSTCoverageUpdates MUST carry the attributes coverageUpdatesID, createDateTime, and language for proper identification and processing of the batch.[RIXML Research Data Dictionary v2.5.1 p.136] [RIXML Research Data Dictionary v2.4 p.132]
- SHOULDCoverageUpdates SHOULD contain one or more CoverageUpdate children; the root has no meaning without at least one update entry.[RIXML Research Data Dictionary v2.5.1 p.136] [RIXML Research Data Dictionary v2.4 p.132]
- SHOULDThe coverageUpdatesID SHOULD be unique (UUIDs are recommended) so consumers can track which batches have been applied and detect duplicates.[RIXML Research Data Dictionary v2.5.1 p.136]
Relationships
- containsCoverageUpdate — CoverageUpdates is the batch container for one or more CoverageUpdate children, each representing an individual coverage change.
- contains-transitivelyCoveragePairing — Through its CoverageUpdate children, CoverageUpdates organises CoveragePairing structures that bind CoveringEntities to CoveredEntities.
- identified-byCoverageUpdates.coverageUpdatesID — The batch identifier coverageUpdatesID enables consumers to track applied batches and identify duplicates.
- qualified-bySpecialtyEnum — In RIXML v3 drafts, SpecialtyEnum qualifies coverage updates to indicate themes or specialties that analysts or teams may cover.
Where It Fits
Canonical Path
Children
Definition
| Type | CoverageUpdatesType |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
coverageUpdatesIDstring |
This is to facilitate the unique identification of a particular batch of coverage 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
CoverageUpdateCoverageUpdateType1..unbounded |
requiredSince 2.5 |
Example
<CoverageUpdates coverageUpdatesID="2024-01-15T09:30:00Z"
createDateTime="2024-01-15T09:30:00Z"
language="eng">
<CoverageUpdate> ... </CoverageUpdate>
</CoverageUpdates>Version History
Unchanged since introduction in RIXML 2.5
CoverageUpdates is documented in RIXML v2.4 (data-dictionary-2.4, p.132) as the root of the Coverage Updates sidecar schema, designed to reuse existing RIXML elements within a new top-level structure for communicating coverage-universe changes (source: data-dictionary-2.5.1, p.136 design rationale).
In RIXML v2.5 the sidecar was reissued as RIXML-CoverageUpdates-2_5.xsd with added support for Themes via Specialty / SpecialtyEnum, allowing thematic coverage to be expressed alongside issuer- and security-level coverage [RIXML Quarterly Update 2017 Q3 p.8]↗.
In RIXML v3 drafts, SpecialtyEnum continues to qualify CoverageUpdates for thematic coverage indication [RIXML v3 Enum Set 5: Subject and Specialty p.1]↗.
Business Rules
DateTime values for coverage updates must be expressed using ISO 8601 format with Zulu time representation
Language identification for coverage items must use ISO 639-2/T standard codes
Coverage update batches should use UUID identifiers to ensure uniqueness and prevent duplicate processing
Design Decisions
Created a dedicated sidecar schema for coverage updates that reuses existing RIXML elements while providing new top-level structure
Provides publishers with a standardized method to communicate coverage information changes to clients and aggregator partners
RIXML Research Data Dictionary v2.5.1, p.136
Coverage update batches require unique identification using recommended UUIDs
Allows consumers to track which batches have been processed and avoid duplicate processing
RIXML Research Data Dictionary v2.5.1, p.136
Semantic Relationships
Constrains1 relationship
The coverage updates batch identifier enables consumers to track which batches have been applied and identify duplicate batches
RIXML Research Data Dictionary v2.5.1, p.136— coverageUpdatesID