THIS VERSION IS NOT THE LATEST RELEVANT DDEX STANDARD. DDEX RECOMMENDS TO USE THE LATEST VERSION.

Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains version 1.3 of the "Release Profiles for Common Release Types"

1 Introduction

The Digital Data Exchange, LLC (DDEX) has, in the past defined a series of message suite standards to make the communication of information along the digital music delivery chain more efficient. As part of these message is the communication of Release details, including information about their parts, i.e. Resources (such as SoundRecording or Videos) and, in some circumstances also Musical Works.

Such descriptions can, however, vary between different uses. For instance describing a Release that contains a single video ringtone track would differ greatly from a Release representing a digital equivalent of a 10-track pop album with previews. Similarly the commercial information regarding a subscription ringtone differs from commercial information regarding a pay-as-you go download.

In order to aid companies that only wish to communicate a small subset of the types of products that the “full” DDEX standards allow DDEX has developed a series of “profiles”. These profiles come in two flavours. Firstly “Release Profiles” that define subsets of Releases to be communicated along the music delivery chain and, secondly, “Business Profiles” that define subsets of the commercial information governing the distribution of Releases.

This standard defines a set of Release Profiles that define how to use the Electronic Release Notification Message Suite Standard to express the most common types of Releases.

The full set of Release and Business Profiles is available from http://ddex.net. Any organisation wishing to implement this (or any other DDEX Standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at http://ddex.net/implementing-ddex-standards.

2 Scope

 2.1 Introduction
This standard defines the Release Profiles for common Release Types. They are provided in two forms: A summary of the differences between this Release Profile and relevant “full” standard and through sample XML code.

Complete, valid, sample XML files supporting these Release Profiles are available for download from http://ddex.net as part of the DDEX.

 2.2 Nomenclature
The following mathematical nomenclature is used in this standard.
  • “0-1” means that at most one (i.e. either none or one) element has to be included in the relevant Profile;
  •  “0-n” means that any number (i.e. either none, one or more) of elements may be included in the relevant Profile; and
  • “1-n” means that at least one element have to be included in the relevant Profile.

The term “mandatory” encompasses the two cardinality expressions “1” and “1-∞”. The term “optional” encompasses the two cardinality expressions “0-1” and “0-∞”.

 2.3 Organisation of the Document
This standard has five clauses and two Annex.

Clauses 1 and 2 provides an introduction and scope as well as defining core terms. Clause 3 then defines the Release Profiles covered by this standard, how Profiles are signalled in a NewReleaseMessage, and how Release structures are captured and how Resource files are communicated. Finally, Clause 4 documents the constrains on the various Release Types defined in this standard.

Annex A then provides information on how to communicate allowed-values defined in a later version of the Electronic Release Notification Message Suite Standard in a message created in accordance with an earlier version of the Electronic Release Notification Message Suite Standard. Annex B provides the sample XML files.

This document also contains information on how to measure whether software is conformant to this standard in the form of conformance weightings. This information is provided in pointy brackets as shown below and needs to be read in conjunction with the relevant DDEX Conformance Standard.

<Conformance Weighting: ...>

Note: conformance weightings are not available for all profiles at this stage.

 2.4 Normative References
The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • Digital Data Exchange (DDEX): Electronic Release Notification Message Suite Standard, Version 3.7

Note: the provisions within this standard are specific to the above-mentioned standard. However, users for older versions of the baseline standards are encouraged to still follow the rules defined herein wherever technically and practically possible as the provisions within this profile standard are accepted best practice for the communication of Release information.

Special notice is given to the definitions, abbreviations and conformance rules used/defined in these standards, which also apply to this standard.

 2.5 Release Notes
Version 1.3 adds support for two new profiles for Single Resource Releases with Cover Art (which augments a profile for Single Resource Releases without Cover Art) and Audio Books. Version 1.3 also adds missing Conformance Weighing and adds rules for all profiles:
  • At least one ResourceReleaseDate or OriginalResoureceReleaseDate should now be provided for each primary Resource if available to the Message Sender  
  • Removal of requirement for pointers from TrackReleases to MainRelease  
  • Handling of percentage fields has been clarified (1/4 is to be expressed as "25" and not ".25").
  • Allowing multiple supporting images for Video Singles

Version 1.2 is a completely re-organised document. While most of the content remains the same, it now contains all applicable rule for a specific profile in one clause. This re-organising lead to a few bugs being detected; they have been removed (for instance, some profiles repeated secondary resources in the bullet on primary resources in Table 1). Version 1.2 also defines clearly what resources a TrackRelease need to contain. The new version introduces a new Profile for Simple Video Releases. Detailed changes include:

  • The requirement to signal primary and secondary resources as such in the ReleaseResourceReference composite;
  • The requirement to signal a LabelName for a Release or, when more than one are provided, that an appropriate LabelNameType is communicated;
  • Clarification on which Release dates need to be communicated;
  • The rule that a UserDefinedValue may only be communicated if the containing element is set to UserDefined.

Version 1.2 also adds support for TV series and film bundles, voice-centric ringtones, and wallpapers. It also specifies that TIS territory codes should not be used for Release Deliveries. Version 1.2 clarifies the communication of artist information. It also corrects an error regarding the title of classical sound recordings.

Finally, Version 1.2 provides Conformance Weightings for one profile for use with the forthcoming DDEX Conformance Standard.

Version 1.1 provides additional Release Profiles to those defined in Version 1.1. Version 1.1 also tightens the rules for some of the profiles based on implementation experiences.

3  Release Profiles

 3.1 Definition of Release Profiles
Special notice is given to the definitions, abbreviations and conformance rules used/defined in these standards, which also apply to this standard.

The Release Profiles defined herein is a subset of the descriptions for Releases, including their components and the order/grouping of such Resources as used in the relevant “full” message suite standard. The differences are described in Table 1. 

Each of the lines of the table defines one Release Profile. The table also defines what to send when communicating a specific Release Profile in a NewReleaseMessage. Typically this is one Main Release and one Track Release for each Primary Resource contained in the Main Resource.

Table 1 — Release Profiles defined in this Standard

Release Profile
Name & description

Releases to be included in a NewReleaseMessage

Main ReleaseTrack Release

1. Audio Single

One or more SoundRecording(s) plus supporting cover image comp

1 Release in accordance with  Clause 4.10 containing

  • Primary Resources:
    • 1-n SoundRecording of type MusicalWorkSoundRecording
  • Secondary resources
    • 1 Image of type FrontCoverImage,
    • 0-n items of bonus material

<Conformance Weighting: 1>


A Track Release in accordance with Clause 4.11 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain:

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

<Conformance Weighting: 1>


2. Video Single

One or more music video recording(s) plus support screen capture image.

1 Release in accordance with  Clause 4.14 containing

  •  Primary Resources
    • 1-n Video of type ShortFormMusicalWorkVideo

  • Secondary Resources
    • 0-n Image of type VideoScreenCapture (typically 1)

    • 0-n items of bonus material

A Track Release accordance with Clause 4.15 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)


3. Mixed Media Bundle

A product with a mixture of several audio and video recordings and potentially images and text, plus supporting screen capture per video track and a single cover image.

1 Release in accordance with Clause 4.6 containing

  •  Primary Resources
    • 0-n SoundRecordings of type MusicalWorkSoundRecording

    • 0-n Videos of type ShortForm­MusicalWorkVideo

    • 0-n Images with a type of either Photograph, FrontCoverImage, BackCoverImage, BookletFrontImage BookletBackImage, Poster or Wallpaper

    • 0-n Texts

    • At least 2 Resources of different types need to be communicated

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n Images of type Video­ScreenCapture

    • 0-n items of bonus material (e.g. such as Images and Booklets)

A Track Release accordance with Clause 4.11 or Clause 4.15 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

4. Audio Album

A product with several audio recordings, some of which may not be not songs, plus supporting cover image, including singles containing more than one Resource. Examples include comedy shows.

1 Release in accordance with Clause 4.4
or
1 Release (for multi-track singles) in accordance with Clause 4.10 containing

  •  Primary Resources
    • 1-n SoundRecordings of type MusicalWorkSoundRecording or NonMusicalWorkSoundRecording

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n items of bonus material

A Track Release in accordance with Clause 4.11 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

5. Video Album

A product with several video recordings, plus screen capture per track and supporting cover image.

1  Release in accordance with Clause 4.13 containing

  •  Primary Resources
    • 1-n Video of type ShortFormMusicalWorkVideo

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n Images of type VideoScreenCapture

    • 0-n items of bonus material

A Track Release accordance with Clause 4.15 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

6. Ringtone

A single audio mobile ringtone clip using a SoundRecioring Resource.

1  Release in accordance with Clause 4.9 containing

  •  Primary Resources
    • 1 SoundRecording of type of either MusicalWorkSoundRecording or NonMusicalWorkSoundRecording or SpokenWordSoundRecording

  • Secondary Resources
    • 0-1 Image of type FrontCoverImage
None

7. MidiRingtone

A single audio mobile ringtone clip using a MIDI Resource.

1  Release in accordance with Clause 4.9 containing

  •  Primary Resources
    • 1 Midi Resource of type of either MonophonicMidi or PolyphonicMidi

  • Secondary Resources
    • 0-1 Image of type FrontCoverImage
None

8. Long-form Music Video

A multi-chapter long form video recording, plus a supporting cover image and potentially a screen capture per chapter.

1 Release in accordance with Clause 4.8 containing

  •  Primary Resources
    • 1 Video with a type of either LongFormMusicalWorkVideo, ConcertVideo or Documentary

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n Images of type VideoScreenCapture

    • 0-n items of bonus material

None

9. Digital Boxed Set

A multi-volume/component digital product made up of a number of other existing digital products, plus supporting cover image(s).

1  Release in accordance with Clause 4.7 containing

  •  Primary Resources
    • 0-n SoundRecordings of type MusicalWorkSoundRecording
    • 0-n Videos of type ShortFormMusicalWorkVideo

  • Secondary Resources
    • 1-n Images of type FrontCoverImage

    • 0-n Images of type VideoScreenCapture

    • 0-n items of bonus material

A Track Release accordance with Clause 4.11 or Clause 4.15 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

The constituent Releases (typically Albums or Bundles) shall not be communicated in the same NewReleaseMessage. If to be offered, these need to be communicated as a Main Release in a separate NewReleaseMessage.

10. Classical Audio Album

A product with several audio recordings, grouped into classical works, plus supporting cover image.

1  Release in accordance with Clause 4.5 containing

  •  Primary Resources
    • 1-n SoundRecordings of type MusicalWorkSoundRecording, albeit with additional elements as defined below

    • 0-n SoundRecordings of type MusicalWorkSoundRecording, without the additional elements referenced in the previous bullet

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n items of bonus material

A Track Release in accordance with Clause 4.11 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
    • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

11. Single Resource Release

A single Resource not for distribution to consumers. Typically provided to a partner for finger printing /rights management type services.

1 Release in accordance with the rules defined in Clause 4.12 containing

  • 1 Primary Resources of any type
  • No Secondary Resource
None

12. TV Series Release

A video product formed from one or more "Episodes", grouped and related to one another.

1 Release with in accordance with the rules defined in Clause 4.16 containing
 

  • Primary Resources
    • 1-n Videos with a type of either Episode, Season, Series or Documentary 
  • Secondary Resource
    • 1 Image of type FrontCoverImage 
    • 0-n Images of type VideoScreenCapture
    • 0-n items of bonus material
None

13. Film Bundle Release

A video product formed from one or more individual Video resources that are collated only for the creation of this product.

1 Release  in accordance with the rules defined in Clause 4.16 containing

  •  Primary Resources
    • 1-n Videos with a type of FeatureFilm or Documentary
  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n Images of type VideoScreenCapture

    • 0-n items of bonus material


None

14. Wall Paper Release

A still image to be used as a wall paper on a mobile device.

1 Release in accordance with the rules defined in Clause 4.17 containing

  • Primary Resources
    • 1 Image of type Wallpaper
  • Secondary Resources
    • 0-n Image(s) of type FrontCoverImage


None

15. Simple Video Single

One or more (music) video recording(s) plus support screen capture image with no Track Release.

This profile is usually used for streaming services.

1 Release in accordance with  Clause 4.14 containing:

Unable to render {multiexcerpt-include} A multiexcerpt-include cannot reference a multiexcerpt which embeds it. Page:3.1 Definition of Release Profiles

 

None

16. Single Resource Release with Cover Art

A single Resource not for distribution to consumers. Typically provided to a partner for finger printing /rights management type services.

1 Release in accordance with the rules defined in Clause 4.18 containing

  • 1 Primary Resources of any type
  • 1 Secondary Resource type FrontCoverImage
None

17. Audio Book

A product with several audio recordings, some of which are not recordings of a book being read or enacted, plus supporting cover image.

1 Release in accordance with Clause 4.19

  •  Primary Resources
    • 1-n SoundRecordings of type NonMusicalWorkSoundRecording

    • 0-n SoundRecordings of type MusicalWorkSoundRecording

  • Secondary Resources
    • 1 Image of type FrontCoverImage

    • 0-n items of bonus material

A Track Release in accordance with Clause 4.11 should be supplied for each primary resource referenced on the Main release, regardless of whether there are any deals available for the Track Release.

The Track Release shall contain

  • Primary Resources:
  • 1-n Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
  • No secondary resources(*)

(*) Note: the LinkedReleaseResourceReference mechanism shall be used to point to the appropriate FrontCoverImage (for Sound Recordings) or VideoScreenCapture (forVideo Resources)

 

 3.2 Signalling a Specific Release Profile
 To indicate in the NewRelaseMessage the use of a specific Profile, the ReleaseProfileVersionId attribute on the root tag of the message shall be set as follows:
CommonReleaseTypes/13/xxx

With “xxx” being the name of the Profile of the Main Release as defined in bold face in column 1 of Table 1 without any space, dash or parentheses characters. For example, a NewReleseMessage for communicating an Audio Album (Music and Speech) defined herein shall have the ReleaseProfileVersionId attribute set to

CommonReleaseTypes/13/AudioAlbumMusicandSpeech

 3.3 Release Structures

 3.3.1 Release Structures for Main Releases
Main Releases shall use the ResourceGroup hierarchy depicted in Figure 1. 

In addition the following rules shall be applied:

  1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
    In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
  2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
  3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
  4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
  5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
  6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
  7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
    1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
    2. Hidden Tracks. <Conformance Weighting: 1>
    Note: this does not apply to Release types that only contain one primary Resource.
  8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>

Figure 1 — Release Structures: Main Releases

Please note, that ResourceGroups are also used to represent multi-part musical works in Classical Audio Albums (see also Clause 5.2.5).

This Clause does not apply to Film Bundles and TV Series Releases.

 3.3.2 Release Structures for Component Releases
Unable to render {include} The included page could not be found.

 3.3.3 Cue Sheet Structure for Longform Viedeo Releases
For Longform Video releases cue sheets are expressed using the CueSheetList. The following rules apply:
  1. Each primary Longform video resource may have a corresponding CueSheet referenced using the VideoCueSheetReference on the resource.
  2. Each CueSheet shall consist of at least one Cue. <Conformance Weighting: 1>
  3. Each Cue shall have a StartTime and Duration. <Conformance Weighting: 1>
  4. For NewReleaseMessages up to version 3.2 each Cue shall reference a SoundRecording resource (using the CueResourceReference) OR a MusicalWork (using the CueWorkReference) included in the NewReleaseMessage. <no Conformance Weighting>
  5. For NewReleaseMessages from version 3.3 upwards each Cue shall include the following referenced creation details directly within the Cue:
    1. It shall contain one ReferencedCreationId of type ISRC or ISWC. <Conformance Weighting: 1>
    2. It shall have exactly one ReferencedCreationTitle of type FormalTitle and a ReferencedCreationTitle of type DisplayTitle shall be provided. <Conformance Weighting: 2>
    3. It shall contain at least one ReferencedCreationContributor. <Conformance Weighting: 2>
    4. It shall contain a HasMusicalContent flag = ‘True’. <Conformance Weighting: 2>
    5. It shall contain a PLine. <Conformance Weighting: 2>
    6. It shall contain a CLine. <Conformance Weighting: 2>

 3.3.4 Chapter Sheet Structure for Longform Viedeo Releases
Unable to render {include} The included page could not be found.

 3.3.5 Physical Releases
A Release that is made available to consumers using a UseType of PurchaseOfPhysicalProduct shall be a Release in accordance with a Relevant Release profile in this Standard and be structured using ResourceGroups, as follows:

5.1.5.1 PhysicalProduct

The top (root) level ResourceGroup represents the Release itself (it is therefore, the same as for digital Release structures)

  • The Product ResouceGroup is mandatory; and
  • The Product ResouceGroup contains either
    • 1-n ComponentProduct (i.e. boxed set); or
    • 1-n Components (i.e. non-boxed set); and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the PhysicalProduct ResourceGroup.

Note: ultimately, each PhysicalProduct contains Components. However, it may be that this relationship is via a ComponentProduct and not direct.

5.1.5.2 ComponentProduct

This ResourceGroup “mirrors” an existing physical product, bundled into a boxed set. It will consist of one or more Components (see below).

  • The ComponentProduct ResouceGroup is optional;
  • The ComponentProduct ResouceGroup shall be identified by a ICPN;
  • The ComponentProduct ResouceGroup shall have a DisplayTitle;
  • The ComponentProduct ResouceGroup shall contain 1-n Components; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the ComponentProduct ResourceGroup.

5.1.5.3 Component

This ResourceGroup represents the physical instance of a sound carrier – i.e. a disk or tape or other sound carrier. It

  • The Component ResouceGroup is mandatory;
  • The Component ResouceGroup shall be identified by a ICPN;
  • The Component ResouceGroup shall have a SoundCarrierType
  • The ComponentProduct ResouceGroup may have a DisplayTitle
  •  The ComponentProduct ResouceGroupmay contain one of the following:
    • 0 or 2 Sides (if only 1 side is present, no Side is required);
    • 2-n Layers; or
    • 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) within the Component ResourceGroup.

Note: the SoundCarrierType is not supported in versions 3.5.x and older.

5.1.5.4 Side

Some SoundCarriers may have 2 sides. This ResouceGroup is not needed for single sided components.

  • A Side ResouceGroupmay contain one of the following:
    • 2-n Layer; or
    • 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) or ResouceGroupContentItems(s) within the Side ResouceGroup.

5.1.5.5 Layer

Some sound carriers may have multiple layers, supporting different media types. This ResouceGroup is not needed for single layered components.

  • A Layer ResouceGroup shall contain 1 TrackList; and
  • A SequenceNumber shall be used to order the ResouceGroup(s) or ResouceGroupContentItems(s) within the Layer ResouceGroup.

5.1.5.6 TrackList

Each component, or side, or layer, ultimately consists if of a sequence ResourceGroupContentItems.

A SequenceNumber shall be used to order the  ResouceGroupContentItems(s) within the TrackList ResouceGroup.

 

 3.3.6. TV Series and Film Bundles
Each TV Series or Film Bundle shall follow the structure shown in Figure 3 below.


Figure 3: Release Structures: TV Series and Film Bundles

 3.4 Communication of Resource Files
When communicating a Release, the message sender shall ensure that for all Resources a Resource File is communicated to the message recipient before the Release (or part of the Release) is to be made available to consumers. For the avoidance of doubt: it is sufficient that the Resource is communicated via a NewReleaseMessage before the Release is to "go live". It is, however, preferred, that all Resources are communicated together (if possible).

When communicating a Resource File, the message sender shall include a TechnicalResourceDetails composite in the relevant Resource composite in the NewReleaseMessage.

When updating Resource information, the message sender is not obliged to re-send Resource Files. The absence of a Resource File for a specific Resource is indicated by the absence of the relevant TechnicalResourceDetails composite.

When the message sender wishes to update a Resource File for a specific Resource, the message sender shall include a TechnicalResourceDetails composite in the relevant Resource composite in the NewReleaseMessage.

4 Release Descriptions

 4.1 Data fields not listed for a specific Release Profile
Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

<Conformance Weighting: 1>

 4.2 Territorial data for Releases or Resources
If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for

  • the territory ‘worldwide’ or
  • for all territories that MessageSender and MessageRecipient have commercial relationships about or
  • for the territories sent in the Deals pertaining to the Release.

If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

  • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

or

  • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

<Conformance Weighting: 1>

 4.3 Data fields common to all Release Profiles
 

The following common rules shall apply to all Releases:

  1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
  2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
    Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
  3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
  4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
  5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
    1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
    2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
    For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
  6. Information about the issuing Label shall be communicated in the LabelName field. 
    1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
    2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
  7. At least one Genre shall be provided. <Conformance Weighting: 1>
  8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
  9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
  10. Deleted.
  11. Deleted.
  12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
    1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
    2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
    3. A DisplayArtist. <Conformance Weighting: 1>
  13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


  14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
  15. (*) For each Release the sender shall provide:
    1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
    2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
    3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
  16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
    1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
    2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
  17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

  18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

    from the one provided for the containing Release. <Conformance Weighting: 2>

  19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
  20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
  21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
  22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
  23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

  24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
    Note: this does not apply to Release types that only contain one primary Resource.
  25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

  26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
  27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

  28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
  29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
  30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
  31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
  32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
  33. Deleted.
  34. All DisplayArtists must be sequenced <Conformance Weighting 1>
  35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
  36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
  37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

     


 4.4 Album
A Release of type Album shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1-n SoundRecordings of type MusicalWorkSoundRecording or NonMusicalWorkSoundRecording

    • Secondary Resources
      • 1 Image of type FrontCoverImage

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of Album. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. A LabelName shall be provided. <Conformance Weighting: 2>
  9. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  10. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.5 Classical Album
A Release of type Classical Album shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1-n SoundRecordings of type MusicalWorkSoundRecording, albeit with additional elements as defined below

      • 0-n SoundRecordings of type MusicalWorkSoundRecording, without the additional elements referenced in the previous bullet

    • Secondary Resources
      • 1 Image of type FrontCoverImage

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of ClassicalAlbum<Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. A LabelName shall be provided. <Conformance Weighting: 2>
  8. At least one IndirectResourceContributors of type Composer or ComposerLyricist shall be communicated if available. <Conformance Weighting: 1>
  9. If a publisher is to be communicated an IndirectResourceContributors of type Music–Publisher shall be communicated. <Conformance Weighting: 2>
  10. The ReferenceTitle of each SoundRecording shall denote the full title of a work. For instance in a CD of Vivaldi’s Four Seasons with 12 tracks (each representing one movement of each of the four concerts), the ReferenceTitles of the first  SoundRecording would be “Concerto No. 1 in E major, Op. 8, RV 269, "La primavera" (Spring), 1. Allegro”. The precise syntax of the ReferenceTitles is left to the MessageSender and may (or may not include a sequence number). Note: The above only applies if the SoundRecording is based on a MusicalWorlk with a hierarchical title. <Conformance Weighting: 2>
  11. A GroupingTitle denoting the parent of each SoundRecording shall be communicated for each territorial variation if the SoundRecording is a MusicalWork that is part of a hierarchical Work. In the above example the Grouping Title for the first three SoundRecordings would be “Concerto for Violin and Strings in E-Major, Op. 8, No. 1, RV 296 ‘La Primavera’”. The precise syntax of GroupingTitles is left to the MessageSender<Conformance Weighting: 1>
  12. A DisplayTitle should be communicated for each territorial variation. This title may be used to communicate concatenations of composer name, GroupingTitle and ReferenceTitle. The DisplayTitle may be omitted if the MessageSender does not want to communicate a specific title string for display purposes. <Conformance Weighting: 2>
  13. ResourceGroups shall be used to communicate both work-related and carrier-related hierarchies. The former shall be indicated by providing a GroupingTitle and the latter by providing an un-typed Title. Work-related hierarchies shall only be provided for SoundRecordings that are based on a MusicalWork that is part of a hierarchical Work <Conformance Weighting: 2>
  14. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
     
  15. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  16. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

    2. This specifically includes the use of work information in the MusicalWorkList composite.

An XML file showing which elements to use is attached to this standard; samples of structured Classical Albums are shown in the table below.

Table 3: Samples of structured Classical Albums (Informative)

Type of Release

Rules for the Release Group

Collection of single segment Works
(e.g. a crossover album with one
segment[1] from three Works each)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 2nd segment (=Track 2)

        ResourceGroup representing the 3rd Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

Collection of multi- segment Works (e.g. a
release with two Works with three segments each)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 4)

               ResourceGroupContentItem representing the 2st segment (=Track 5)

               ResourceGroupContentItem representing the 3rd segment (=Track 6)

Single Work with multiple segments

ResourceGroup representing the disc containing

        ResourceGroup representing the Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

Works and “tracks” mixed (disc containing
one Work with two segments, one track, a
second Work with two segments and a track)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 4)

               ResourceGroupContentItem representing the 1st 2nd segment (=Track 5)

        ResourceGroupContentItem representing the 1st segment (=Track 3)

        ResourceGroupContentItem representing the 1st segment (=Track 6)

Same Work repeated in product (disk with
segments one and two of the Work, then
segments one and two of a second Work
followed by segments three and four of the
first Work)

ResourceGroup representing the disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

        ResourceGroup representing the 2nd Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 3)

               ResourceGroupContentItem representing the 1st segment (=Track 4)

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 5)

               ResourceGroupContentItem representing the 4th segment (=Track 6)

Work spanning multiple discs (disk one
containing one Work with three segments
and disk two containing two further
segments of the same Work)

ResourceGroup representing the 1st disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 1st segment (=Track 1)

               ResourceGroupContentItem representing the 2st segment (=Track 2)

ResourceGroup representing the 2nd disc containing

        ResourceGroup representing the 1st Work containing

               ResourceGroupContentItem representing the 3rd segment (=Track 3)

               ResourceGroupContentItem representing the 4th segment (=Track 4)



[1] A typical “segment” would be a work. A segment itself can be segmented itself using a ResourceGroup instead of a ResourcegroupContentItem.


 4.6 Mixed Media Bundle
A Release of type Mixed Media Bundle shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 0-n SoundRecordings of type MusicalWorkSoundRecording

      • 0-n Videos of type ShortForm­MusicalWorkVideo

      • 0-n Images with a type of either Photograph, FrontCoverImage, BackCoverImage, BookletFrontImage BookletBackImage, Poster or Wallpaper

      • 0-n Texts

      • At least 2 Resources of different types need to be communicated

    • Secondary Resources
      • 1 Image of type FrontCoverImage

      • 0-n Images of type Video­ScreenCapture

      • 0-n items of bonus material (e.g. such as Images and Booklets)

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of MultimediaSingle or MultimediaBundle. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC if they are a SoundRecording or a music Video. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. Video screen captures, if included, shall be linked from the Video Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription or VideoScreenCapture. <Conformance Weighting: 2>
  9. A LabelName shall be provided. <Conformance Weighting: 2>
  10. All other elements that are not technically mandatory may be omitted or, if provided, may be ignored by the recipient of the DDEX message.
  11. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  12. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

An XML file showing which elements to use is attached to this standard.

 

 

 4.7 Digital Boxed Set
A Release of type DigitalBoxedSet shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 0-n SoundRecordings of type MusicalWorkSoundRecording
      • 0-n Videos of type ShortFormMusicalWorkVideo

    • Secondary Resources
      • 1-n Images of type FrontCoverImage

      • 0-n Images of type VideoScreenCapture

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of DigitalBoxSetRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. A LabelName shall be provided. <Conformance Weighting: 2>
  9. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  10. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

  11. The Release Creator may provide titles fir the components of the box set by providing a Title composite in the appropriate ResourceGroup composite. The TitleType shall be set to GroupingTitle. <Conformance Weighting: 2>
  12. LinkedReleaseResourceReferences shall be used to link from the box set ResourceGroup to the appropriate Resource. <Conformance Weighting: 1>

An XML file showing which elements to use is attached to this standard.

 4.8 Long-form Musical Work Video Release
A Release of type LongFormMusicalWorkVideoRelease be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1 Video with a type of either LongFormMusicalWorkVideo, ConcertVideo or Documentary

    • Secondary Resources
      • 1 Image of type FrontCoverImage

      • 0-n Images of type VideoScreenCapture

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of LongFormMusicalWorkVideoRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. Video screen captures, if included, shall be linked from the Video Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription or VideoScreenCapture. <Conformance Weighting: 1>
  9. The following constraints for cues shall be communicated:
    1. Each primary Longform video resource may have a corresponding CueSheet referenced using the VideoCueSheetReference on the resource.
    2. Each CueSheet shall consist of at least one Cue. <Conformance Weighting: 1>
    3. Each Cue shall have a StartTime and Duration. <Conformance Weighting: 1>
    4. For NewReleaseMessages up to version 3.2 each Cue shall reference a SoundRecording resource (using the CueResourceReference) OR a MusicalWork (using the CueWorkReference) included in the NewReleaseMessage. <no Conformance Weighting>
    5. For NewReleaseMessages from version 3.3 upwards each Cue shall include the following referenced creation details directly within the Cue:
      1. It shall contain one ReferencedCreationId of type ISRC or ISWC. <Conformance Weighting: 1>
      2. It shall have exactly one ReferencedCreationTitle of type FormalTitle and a ReferencedCreationTitle of type DisplayTitle shall be provided. <Conformance Weighting: 2>
      3. It shall contain at least one ReferencedCreationContributor. <Conformance Weighting: 2>
      4. It shall contain a HasMusicalContent flag = ‘True’. <Conformance Weighting: 2>
      5. It shall contain a PLine. <Conformance Weighting: 2>
      6. It shall contain a CLine. <Conformance Weighting: 2>
  10. The following constraints for chapters shall be communicated:
    1. Each collection item shall have the collection type ‘VideoChapter’. <Conformance Weighting: 1>
    2. Each collection item shall have a proprietary CollectionId. <Conformance Weighting: 1>
    3. Each collection item shall have one Title. <Conformance Weighting: 1>
    4. Each collection item shall have an IsComplete flag set to ‘True’ <Conformance Weighting: 2>
    5. Each collection item shall have a CollectionResourceReferenceList containing one reference to the Video representing the primary resource on the Longform release. <Conformance Weighting: 1>
    6. Each collection item may have a RepresentativeImageReference which references the screen capture Image resource representing that chapter. <Conformance Weighting: 2>
    7. The primary Video resource shall have a SoundRecordingCollectionReference for each ‘VideoChapter’ collection item. <Conformance Weighting: 1>
    8. Each SoundRecordingCollectionReference on the primary Video resource shall have a StartTime indicating the chapter start time on the Video. <Conformance Weighting: 1>
  11. Each primary long form Video resource on the release shall contain a reference to a cue sheet as follows <Conformance Weighting: 2>:
    1. Each primary Longform video resource may have a corresponding CueSheet referenced using the VideoCueSheetReference on the resource.
    2. Each CueSheet shall consist of at least one Cue. <Conformance Weighting: 1>
    3. Each Cue shall have a StartTime and Duration. <Conformance Weighting: 1>
    4. For NewReleaseMessages up to version 3.2 each Cue shall reference a SoundRecording resource (using the CueResourceReference) OR a MusicalWork (using the CueWorkReference) included in the NewReleaseMessage. <no Conformance Weighting>
    5. For NewReleaseMessages from version 3.3 upwards each Cue shall include the following referenced creation details directly within the Cue:
      1. It shall contain one ReferencedCreationId of type ISRC or ISWC. <Conformance Weighting: 1>
      2. It shall have exactly one ReferencedCreationTitle of type FormalTitle and a ReferencedCreationTitle of type DisplayTitle shall be provided. <Conformance Weighting: 2>
      3. It shall contain at least one ReferencedCreationContributor. <Conformance Weighting: 2>
      4. It shall contain a HasMusicalContent flag = ‘True’. <Conformance Weighting: 2>
      5. It shall contain a PLine. <Conformance Weighting: 2>
      6. It shall contain a CLine. <Conformance Weighting: 2>
  12. Each primary long form Video resource on the release shall contain 1 to many references to chapters as follows <Conformance Weighting: 2>:
    1. Each collection item shall have the collection type ‘VideoChapter’. <Conformance Weighting: 1>
    2. Each collection item shall have a proprietary CollectionId. <Conformance Weighting: 1>
    3. Each collection item shall have one Title. <Conformance Weighting: 1>
    4. Each collection item shall have an IsComplete flag set to ‘True’ <Conformance Weighting: 2>
    5. Each collection item shall have a CollectionResourceReferenceList containing one reference to the Video representing the primary resource on the Longform release. <Conformance Weighting: 1>
    6. Each collection item may have a RepresentativeImageReference which references the screen capture Image resource representing that chapter. <Conformance Weighting: 2>
    7. The primary Video resource shall have a SoundRecordingCollectionReference for each ‘VideoChapter’ collection item. <Conformance Weighting: 1>
    8. Each SoundRecordingCollectionReference on the primary Video resource shall have a StartTime indicating the chapter start time on the Video. <Conformance Weighting: 1>
  13. A LabelName shall be provided. <Conformance Weighting: 2>
  14. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  15. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.9 Ringtone Clip
A Release of type RingtoneClip shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1 SoundRecording of type of either MusicalWorkSoundRecording or NonMusicalWorkSoundRecording or SpokenWordSoundRecording

    • Secondary Resources
      • 0-1 Image of type FrontCoverImage
  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of RingtoneRelease or RingbackToneRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC if the Release is a Ringtone bases on a SoundRecording. <Conformance Weighting: 1>
  6. Primary Resources shall be identified with a ProprietaryId if the Release is a Ringtone bases on a MIDI Resource. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. A LabelName shall be provided. <Conformance Weighting: 2>
  9. A RelatedRelease of type IsReleaseFromRelelease shall be provided if such a Release exists and the Message sender has reasonable access to it. <Conformance Weighting: 2>
  10. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  11. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.10 Single
A Release of type Single shall be communicated with the following rules.
  1. The Release shall contain
    • Primary Resources:
      • 1-n SoundRecording of type MusicalWorkSoundRecording
    • Secondary resources
      • 1 Image of type FrontCoverImage,
      • 0-n items of bonus material

    <Conformance Weighting: 1>

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of Single. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. A LabelName shall be provided. <Conformance Weighting: 2> 
  9. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  10. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.11 Track Release
A Release of type TrackRelease shall be communicated with the following rules.
  1. The Release shall contain
    • Primary Resources:
      • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
    • No secondary resources(*)

    <Conformance Weighting: 1>

  2. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

  3. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  4. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  5. The Release shall have a ReleaseType of TrackRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  6. The Release shall be uniquely identified. <Conformance Weighting: 1> Note: Some record companies may use a compound identifier to Track Releases concatenating, for instance (i) the ID for the Album Release that the Track Release was taken from and (ii) the Resource ID for the Primary Resource contained in the Track. This allows labels to keep track of the “context” of a Track Release. <Conformance Weighting: 1>
  7. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  8. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  9. The following resource structure shall be communicated (see also Clause 3.3.2):
    Error rendering macro 'excerpt-include' : No link could be created for '3.3.2 Release Structures for Component Releases'.
  10. A LabelName shall be provided. <Conformance Weighting: 2>

An XML file showing which elements to use is attached to this standard.

 4.12 Single Resource Release
A Release of type SingleResourceReleaseshall be communicated with the following rules.
  1. The Release shall contain
    • 1 Primary Resources of any type
    • No Secondary Resource
  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of SingleResourceRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or an ISRC. <Conformance Weighting: 1>
  5. The one Primary Resource shall be identified with an ISRC. <Conformance Weighting: 1>
  6. No Secondary Resources should be supplied. <Conformance Weighting: 1>
  7. No release resource structure should be provided. <Conformance Weighting: 1>
  8. A LabelName shall be provided. <Conformance Weighting: 2>
  9. A RightShare for the publisher, owning the right share and the company administering the rights may be provided with
    1. A RightShareReference; <Conformance Weighting: 1>
    2. The list of TerritoryCodes (or ExcludedTerritoryCodes) that identify the territorial reach of the RightsClaim <Conformance Weighting: 1>;
    3. The FullName of the RightsController <Conformance Weighting: 1>;
    4. The RightsAdministratorRole <Conformance Weighting: 1> and
    5. A ValidityPeriod if known. <Conformance Weighting: 2>
  10. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  11. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.13 Video Album
A Release of type VideoAlbum shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1-n Video of type ShortFormMusicalWorkVideo

    • Secondary Resources
      • 1 Image of type FrontCoverImage

      • 0-n Images of type VideoScreenCapture

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of VideoAlbum. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. Video screen captures, if included, shall be linked from the Video Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription or VideoScreenCapture. <Conformance Weighting: 2>
  9. A LabelName shall be provided. <Conformance Weighting: 2>
  10. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  11. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.14 Video Single
A Release of type VideoSingle shall be communicated with the following rules.
  1. The Release shall contain
    •  Primary Resources
      • 1-n Video of type ShortFormMusicalWorkVideo

    • Secondary Resources
      • 0-n Image of type VideoScreenCapture (typically 1)

      • 0-n items of bonus material

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of VideoSingle. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  8. Video screen captures, if included, shall be linked from the Video Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription or VideoScreenCapture. <Conformance Weighting: 2>
  9. A LabelName shall be provided. <Conformance Weighting: 2>
  10. A RelatedRelease of type IsEquivalentToAudio may be provided if such information is available.  <Conformance Weighting: 2>
  11. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  12. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

 4.15 Video Track Release
A Release of type VideoTrackRelease shall be communicated with the following rules.
  1. The Release shall contain
    • Primary Resources:
      • 1 Resource of the type prevalent in the Main Release that the Track Release is communicated alongside with
    • No secondary resources(*)

    <Conformance Weighting: 1>

  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of VideoTrackRelease. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISRC. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. The following resource structure shall be communicated (see also Clause 3.3.2):
    Error rendering macro 'excerpt-include' : No link could be created for '3.3.2 Release Structures for Component Releases'.
  8. A LabelName shall be provided. <Conformance Weighting: 2>
  9. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  10. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

  11. Video screen captures, if included, shall be linked from the Video Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription or VideoScreenCapture. <Conformance Weighting: 2>

An XML file showing which elements to use is attached to this standard.

 4.16 TV Series and Film Bundles
A Release of type TvSeries or FilmBundle shall be communicated with the following rules.
  1. The Release shall contain
    • Primary Resources
      • 1-n Videos with a type of either Episode, Season, Series or Documentary 
    • Secondary Resource
      • 1 Image of type FrontCoverImage 
      • 0-n Images of type VideoScreenCapture
      • 0-n items of bonus material
  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of Series or FilmBundle. <Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN. <Conformance Weighting: 1>
  5. Primary Resources shall be identified with an ISAN, VIASN or ProprietaryId. <Conformance Weighting: 1>
  6. Secondary Resources shall be identified by a ProprietaryId. <Conformance Weighting: 1>
  7. A LabelName shall be provided. <Conformance Weighting: 2>
  8. The Release shall contain a CollectionList containing Collections representing all necessary groupings of Resources such as series and seasons (see also Clause 3.3.6). <Conformance Weighting: 1>
  9. The Collection that represents the grouping of Resources to be offered through the Release shall be the only Collection containing a EquivalentReleaseReference <Conformance Weighting: 1>
  10. Each Collection shall have an appropriate CollectionType. <Conformance Weighting: 1>
  11. The link from a Collection to its constituent Collections shall contain only the reference and the sequence number. <Conformance Weighting: 1>
  12. The link from a Collection to its constituent Resources shall shall contain only the reference and the sequence number.  <Conformance Weighting: 1>
  13. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  14. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  15. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

  16. The IsComplete flag shall not be provided as part of the CollectionDetailsByTerritory composite. <Conformance Weighting: 2>


     

An XML file showing which elements to use is attached to this standard.

 

 4.17 Wallpaper Release
A Release of type WallpaperRelease shall be communicated with the following rules:
  1. The Release shall contain
    • Primary Resources
      • 1 Image of type Wallpaper
    • Secondary Resources
      • 0-n Image(s) of type FrontCoverImage
  2. Rules common to all Release Profiles:
    1. Primary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to PrimaryResource. <Conformance Weighting: 1>
    2. Secondary Resources shall have the  ReleaseResourceType attribute in the ReleaseResourceReference that links from a Release to a Resource set to SecondaryResource.  <Conformance Weighting: 1>
      Note: All Resources must, in the ResourtceGroup be identified as either a PrimaryResouce or a SecindaryResource and show their related ResourceType (e.g. SoundRecording or Video).
    3. Within the ResourceList composite, at least one Resource has to be present. Resources need to be provided in the order they appear in the XML Schema. However, that order does not imply that the Resources are sequenced. To sequence resources, the ResourceGroup composite has to be used. <Conformance Weighting: 1>
    4. At least one Title of type FormalTitle and a Title of type DisplayTitle shall be provided for in the default ReleaseDetailsByTerritorySection, in addition a single ReferenceTitle. Additional variants of these titles may be provided to support translations or territorial variations where applicable. <Conformance Weighting: 1>
    5. A PLine shall be provided and a CLine may be communicated. If a CLine is provided, the recipient shall ingest it.  
      1. It is permissible that the Pline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a PLine; <Conformance Weighting: 1>
      2. It is permissible that the Cline is communicated on a global level or on a territorial level. The sender must ensure that for each territory communicated there is a CLine; <Conformance Weighting: 1>
      For the avoidance of doubt, it is permissible to provide a global PLine and then to override it for some territories in the same message. The same applies to CLines.
    6. Information about the issuing Label shall be communicated in the LabelName field. 
      1. There needs to be one LabelName for each territory for which a deal is provided. Unless a LabelName appears in the ReleaseDetailsByTerritory composite with TerritoryCode Worldwide, all other ReleaseDetailsByTerritory composite shall contain a LabelName. <Conformance Weighting: 2>  
      2. If more than one LabelName is provided, one shall be a DisplayLabel. It is this DisplayLabel that shall be used by DSPs for display and search. <Conformance Weighting: 2>
    7. At least one Genre shall be provided. <Conformance Weighting: 1>
    8. The appropriate ParentalWarningType shall be provided. <Conformance Weighting: 1>
    9. At least one ReleaseDate or OriginalReleaseDate (the former is preferred) should be provided for the Release if available to the Message Sender. <Conformance Weighting: 2>
    10. Deleted.
    11. Deleted.
    12. For each Resource the sender shall provide the following Parties. Parties listed as a ResourceContributor may be repeated as DisplayArtistsfor the same Resource as long as their Role differs.
      1. All IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor information it has reasonable access to. Data that the sender has no authority, for instance because of contractual obligations, should not be communicated. Note: Indirect*Contributors identify a contributor to the MusicalWork used. This applies especially to contributors with roles such as Composer and/or ComposerLyricist. <Conformance Weighting: 2>
      2. All contributors to the SoundRecording (or other Resource) that is not a DisplayArtist for the same role. <Conformance Weighting: 1>
      3. A DisplayArtist. <Conformance Weighting: 1>
    13. Parties listed as a ResourceContributor may be repeated as DisplayArtists for the same Resource as long as their Role differs. <Conformance Weighting: 1>


    14. Parties that play a role as an IndirectResourceContributor and a (direct) ResourceContributor shall be communicated in both composites. <Conformance Weighting: 2>
    15. (*) For each Release the sender shall provide:
      1. A ReleaseType as defined in this Clause. The MessageSender may include more detailed ReleaseType information in addition to the defined ReleaseType using the UserDefinedValue attribute. Such information would primarily be used for marketing information that do not affect the processing of such Releases. <Conformance Weighting: 1>
      2. A DisplayArtist composite for each artist whose name is to be displayed prominently for the Release. <Conformance Weighting: 1>
      3. Exactly one DisplayArtist-Name for the Release (by territory) providing a string that the Release Creator suggests to be used. <Conformance Weighting: 2>
    16. (*) To communicate "compound artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs from the one provided for the containing Release.
      1. A DisplayArtistName showing the full name of the compound artist as it should be displayed <Conformance Weighting: 2>
      2. A DisplayArtist composite for each of the parties that make up the compound artist. The main artist (in the example above Carlos Santana) shall have a RoleCode of "MainArtist" and the featured artist (Eric Clapton) shall have a RoleCode of "FeaturedArtist" <Conformance Weighting: 2>
    17. When communicating "compound artists" (e.g. "John & Paul"), the string representing the name for the compound artist shall be communicated in the DisplayArtistName. The constituent artists ("John" and "Paul") should be communicated, individually in the DisplayArtist composite. It is, however, also permissible to communicate compound name ("John & Paul") in the DisplayArtist composite should the MessageSender be unable, despite best effort, to separate out the constituent artists' names. It should be noted that some companies have established rules for concatenating the constituent components of a compound artist (in the above example an ampersand has been used) and that DDEX, while acknowledging the existence of such rules, does not standardise them. <Conformance Weighting: 1>

    18. A DisplayArtistName shall only provided on Resource level if the Resource's DisplayArtistName differs

      from the one provided for the containing Release. <Conformance Weighting: 2>

    19. The parties listed in IndirectSoundRecordingContributor, IndirectVideoContributor or IndirectMidiContributor may be repeated as DisplayArtists on Resource and Release. <Conformance Weighting: 2>
    20. If a Party is playing multiple roles when creating a SoundRecording or Video, only one Contributor composite shall be provided and all roles the party plays shall be included in that one Contributor field. <Conformance Weighting: 1>
    21. If a Party is playing multiple roles when creating a MusicalWork underpinning a SoundRecording or Video, only one IndirectContributor composite shall be provided and all roles the party plays shall be included in that one IndirectContributor field. <Conformance Weighting: 1>
    22. If MusicalWork details are provides and if such information contains a RightsClaim, then the total of all RightsClaimPercentages for each MusicalWork may not exceed 100%. <Conformance Weighting: 1>
    23. The CatalogTransfer composite may only be used in the context of the Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders. <Conformance Weighting: 1>

    24. To communicate that a Resource is either hidden, a bonus resource, an instant-gratification or pre-order incentive resource, the respective flag(s) on the ResourceGroupContentItem shall be used. The flags on Resource shall not be used. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    25. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1>

    26. The rules marked with an asterisk in parenthesis in this sub-clause do not apply to the two ClassicalAudio profiles. <Conformance Weighting: 1>
    27. DisplayArtist and DisplayArtistName need to be provided on Release and Resource level. And they need contain the same information unless the Release artist and Resource artist are genuinely different. This is typically the case for compilation albums and albums of a main artist working with a number of (differenced) featured artists. <Conformance Weighting: 1>

    28. While for Classical Audio Album Releases, the same rules apply the provision of “creative” IndirectResourceContributors is crucial.  "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator. <Conformance Weighting: 1>
    29. In version 3.6 or previous, there is no DisplayArtistName on Resource level. In that case it is recommended to use a DisplayArtist composite with a UserDefined RoleCode of "DisplayArtistName". <Conformance Weighting: 1>
    30. All identifiers with a published syntax shall conform to that syntax. <Conformance Weighting: 1>
    31.  It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongside and when the containing element contains "UserDefined" <Conformance Weighting: 1>
    32. It is not permissible to communicate a Comment in the MessageHeader. Comments can be included into an XML file using the <!-- ... --> syntax but such comments would be ignored by any automated ingestion process. <Conformance Weighting: 2>
    33. Deleted.
    34. All DisplayArtists must be sequenced <Conformance Weighting 1>
    35. All sequence numbers shall start with 1 for a given entity in a given context and be incremented by 1 for each subsequent entity.  <Conformance Weighting 1> 
    36. Percentages shall be provided in the interval [0,100] unless the HasMaxValueOfOne attribute is set to true. In that case Percentages shall be provided in the interval [0, 1] with 1 representing 100%. <Conformance Weighting 1> 
    37. The MessageID element shall be, in combination of the DDEX Party ID of the MessageSender, globally unique. Thus, a MessageSender shall never re-use a MessageID. <Conformance Weighting 1> 

       


  3. The Release shall have a ReleaseType of WallpaperRelease<Conformance Weighting: 1>
    Note: more granular, user-defined, ReleaseTypes may be added in addition to the mandatory DDEX-defined ReleaseType.
  4. The Release shall be identified by either a GRid or by an ICPN.  <Conformance Weighting: 1>
  5. Primary Resources shall be identified with a ProprietaryId<Conformance Weighting: 1>
  6. The following resource structure shall be communicated (see also Clause 3.3.1):
    1. Main Releases  shall have the IsMainRelease flag set to True. <Conformance Weighting: 1>
      In older versions of the Release Notification Message Suite Standard, where the IsMainRelease flag is not available, the same functionality can be achieved by (i) placing the main Release as the first Release into the ReleaseList composite and using a ReleaseReference of “R0”.
    2. Track bundle resource groups  shall be sequenced. <Conformance Weighting: 1>
    3. All Primary Resources (even if there is only one) shall be sequenced in the context of their track bundle ResourceGroup (i.e. the sequence restarts with the next track bundle).<Conformance Weighting: 1>
    4. Secondary Resources (e.g. cover images) content items shall not be sequenced.<Conformance Weighting: 2>
    5. For each primary Resource, at least one Release Date (i.e. either original and/or global and/or territorial) shall be provided. <Conformance Weighting: 1>
    6. For each Resource, the sender shall province any IndirectSoundRecordingID. IndirectVideoID or IndirectMidiId, identifying the MusicalWork (preferably an ISWC) used, that it has reasonable access to. <Conformance Weighting: 1>
    7. To indicate that a Resource is a pre-order incentive track or a hidden track on a Release, the respective Attributes in the relevant ResourceGroupContentItem shall be used:
      1. Pre-order incentive  Tracks. <Conformance Weighting: 1>
      2. Hidden Tracks. <Conformance Weighting: 1>
      Note: this does not apply to Release types that only contain one primary Resource.
    8. The relevant flags to signal bonus, pre-order incentive and/or hidden tracks on Resource level shall not be used. <Conformance Weighting: 1>
  7. A LabelName shall be provided.  <Conformance Weighting: 2>
  8. Rules for territorial variations of Release descriptions:
    1. If no territorial variations exist then the release shall have only one ReleaseDetailsByTerritory composites per Release or Resource carrying all the applicable details. This shall be provided either for
      • the territory ‘worldwide’ or
      • for all territories that MessageSender and MessageRecipient have commercial relationships about or
      • for the territories sent in the Deals pertaining to the Release.

      If there are territorial variations then multiple ReleaseDetailsByTerritory composites need to be provided per Release or Resource. These can be provided in one of two ways:

      • Either each ReleaseDetailsByTerritory composite is provided for a single territory or group of territories, containing a full set of information;

      or

      • One default ReleaseDetailsByTerritory composite, defined by being either for “worldwide” or for all territories that MessageSender and MessageRecipient have commercial relationships about, carries the default data. The remaining ReleaseDetailsByTerritory composite provide the details for data values that are different to the default values only (per territory or territories). Data fields not provided in the remaining ReleaseDetailsByTerritory composite are inherited from the default ReleaseDetailsByTerritory composite.

      The level of granularity for a territorial variation is an object (i.e. a composite or simple tag) directly contained in the ...DetailsByTerritory composite. Any object that has a territorial variation needs to be repeated in its entirety; an object's absence shall be interpreted as having no territorial variation of that object for the given territory or territories.

      <Conformance Weighting: 1>

  9. Rules for data fields not communicated:
    1. Any data fields or composite not discussed for a specific Release Profile may still be used by the creator/sender of a relevant DDEX message; the recipient may, however, discard any such information at its own discretion.

      <Conformance Weighting: 1>

     

An XML file showing which elements to use is attached to this standard.

Annexes

 Annex A (informative) Communication of Allowed Values defined in a later Standard
In order to communicate an allowed values defined by DDEX later than the message format used in the communication between two business partners the following approach shall be taken:
  1. The element shall contain the value “UserDefined”;
  2. The UserDefinedValue attribute shall be set to the value from the later standard; and
  3. The Namespace attribute shall be set to the same value as defined as normative content for the MessageVersionId attribute for that standard.

For example, to communicate a UseType of KioskDownload, a term defined for Version 3.3 of the Release Notification Standard in a Version 3.2 message the following XML code shall be used:

<UseType UserDefinedValue="KioskDownload" Namespace="ern/33">
   UserDefinedValue
</UseType>

 Annex B (normative) XML Samples
Normative XML Samples are provided in separate files as detailed below. Conformance requires looking at the relevant Release Profile files (defined here) and the relevant Business Profile files (defined elsewhere).

The XML Sample files are named in one of three ways:

The Business Profile samples are named Profile_xxx.xml or Profile_xxx_yyy.xml with xxx and yyy being the name of the Profile, or ProfileVariant_xxx.xml for a variant of a profile for a specific use case.



Evaluation Licence for DDEX Standards

 

 

Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.

No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. The non-infringement of any third party intellectual property rights related to the DDEX Standards.

Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).

Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.

Write a comment…