EntitlementGroup
RIXML 2.5 Element
Acts as a structural container for organizing access control specifications that govern research distribution. Groups related entitlement conditions that apply conjunctively to determine content accessibility.
A composite restriction on the use of the product. Each individual entitlement specification inside a single EntitlementGroup applies conjuctively with the others in the group -- i.e. they are AND-ed together. For example, you could limit readership to American press agencies by including a LocationEntitlement (containing a Country element with the U.S. country code) and an AudienceTypeEntitlement (containing the Media audience type code). Each EntitlementGroup applies disjunctively with the other EntitlementGroups -- i.e. they are OR-ed together.
Usage
Include zero to multiple EntitlementGroup elements within ProductDetails when research requires access restrictions. Each group must contain at least one child Entitlement element defining specific access conditions.
Business Context
Supports compliance and business model requirements by enabling fine-grained control over research distribution based on client characteristics, geographic location, and temporal constraints.
Specification Guide
Overview
EntitlementGroup is a container element that bundles one or more Entitlement specifications into a single logical access-control unit for a research product. It implements composite access restrictions using boolean logic: individual Entitlement children within a single group are combined conjunctively (AND), while multiple sibling EntitlementGroup elements are combined disjunctively (OR). This two-level structure allows publishers to express sophisticated distribution policies — for example, restricting content to American press agencies by combining a country Entitlement and an audience-type Entitlement within one group, while permitting an alternative audience through a separate group.
Usage
EntitlementGroup appears as an optional, repeatable (zero-or-more) child of ProductDetails within the Context package, and is also permitted within EventVenue for event-related access control (sources: data-dictionary-2.4 p.48, data-dictionary-2.5.1 p.51). When present, each group must contain at least one Entitlement child. Typical authoring patterns: - Single restrictive policy: one EntitlementGroup containing several Entitlement children, all of which must be satisfied (e.g. CountryEntitlement + AudienceTypeEntitlement). - Alternative access paths: multiple EntitlementGroup elements, each representing an independent set of conditions that, if any one is met, grants access. - Vendor-specific codes: when expressing vendor-platform entitlements, place each vendor's codes in its own EntitlementGroup and use the entitlementContext attribute on contained entitlements to identify the platform (e.g. "Bloomberg", "ThomsonReuters") [RIXML Research Data Dictionary v2.5.1 p.20]. Design the AND/OR structure carefully — the choice of how to partition entitlements across groups directly determines whether conditions are cumulative or alternative.
Rules
- MUSTWhen present, an EntitlementGroup must contain at least one Entitlement child element.[RIXML Level One Addendum v2.2 p.27] [RIXML Level One Addendum v2.3 p.22] [RIXML Level One Addendum v2.3.1 p.22] [RIXML Level One Addendum v2.4 p.22] [RIXML Level One Addendum v2.5 p.22]
- INFORMATIVEEntitlement children within a single EntitlementGroup are combined using AND logic, while multiple sibling EntitlementGroup elements are combined using OR logic.[RIXML User Guide v2.1 p.34] [RIXML User Guide v2.3 p.35] [RIXML User Guide v2.3.1 p.35] [RIXML Research Data Dictionary v2.4 p.48] [RIXML Research Data Dictionary v2.5.1 p.51]
- SHOULDEach vendor-specific entitlement code should appear in its own AudienceTypeEntitlement inside a distinct Entitlement and EntitlementGroup, so that vendor systems can process their codes independently.[RIXML Research Data Dictionary v2.4 p.20] [RIXML Research Data Dictionary v2.5.1 p.20]
Relationships
- child-ofProductDetails — EntitlementGroup is an optional, zero-or-more child of ProductDetails within the Context package, where it scopes access restrictions to the research product.
- child-ofEventVenue — EntitlementGroup may also appear within EventVenue to scope access restrictions for event-related content.
- containsEntitlement — EntitlementGroup contains one or more Entitlement children. Their semantic combination is conjunctive within a group and disjunctive across groups.
- influenced-byRatingActionEnum.Restricted — When a rating action is marked Restricted, the distribution entitlements expressed through EntitlementGroup determine who may receive the affected research.
Where It Fits
Canonical Path
Children
Definition
| Type | |
| Namespace | http://www.rixml.org/2017/9/RIXML |
| Min Occurs | 1 |
| Max Occurs | 1 |
Attributes
No attributes defined for this element
Children
EntitlementEntitlementType1..unbounded |
requiredSince 2.1 |
Example
<EntitlementGroup>
<Entitlement> ... </Entitlement>
</EntitlementGroup>Version History
Unchanged since introduction in RIXML 2.1
EntitlementGroup is present from at least RIXML 2.1 onward with stable semantics: a zero-or-more container under ProductDetails requiring at least one Entitlement child, applying AND-within / OR-between logic [RIXML User Guide v2.1 p.34]. From 2.4 onward, documentation explicitly notes its availability within EventVenue as well as ProductDetails [RIXML Research Data Dictionary v2.4 p.48]. Version 2.5 documentation also lists ProductSeries as a permitted parent [RIXML Research Data Dictionary v2.5.1 p.51]. Guidance on coding vendor-specific entitlement codes (one vendor per group, identified via entitlementContext) is documented from 2.4 and reiterated in 2.5 (sources: data-dictionary-2.4 p.20, data-dictionary-2.5.1 p.20).
Business Rules
Each vendor-specific entitlement code must appear in its own distinct AudienceTypeEntitlement element within separate Entitlement and EntitlementGroup elements
Each EntitlementGroup element must contain at least one Entitlement element
Semantic Relationships
Requires1 relationship
Vendor-specific entitlement codes should each appear within their own distinct AudienceTypeEntitlement element within separate Entitlement and EntitlementGroup elements
RIXML Research Data Dictionary v2.5.1, p.20— How to Code Vendor-Specific Entitlement Codes
Constrains1 relationship
Individual entitlements within a single EntitlementGroup apply conjunctively (AND-ed together), while multiple EntitlementGroups apply disjunctively (OR-ed together)
RIXML Research Data Dictionary v2.5.1, p.51— EntitlementGroup
Triggers Action1 relationship
When a rating is marked as restricted, it affects the distribution entitlements and limits who can access the research publication
RIXML Research Data Dictionary v2.5.1, p.98— Restricted