Regardless of the Profile, a NewReleaseMessage needs to contain exactly one Main Release.

A NewReleaseMessage needs to contain none, one, or many Track Releases as defined in Clause 5.1.2 (Basic Release Profiles and Profile Variants) below.

Where Clause 5.1.2 (Basic Release Profiles and Profile Variants) indicates that Track Releases(s) need to be provided, the NewReleaseMessage must contain exactly one TrackRelease composite in accordance with Clause 5.6 (Track Release) for each Primary Resource referenced in the Main Release, regardless of whether there are any deals available for the TrackRelease.

the Profile-specific rules set out or referenced in Clause 5.1.2 (Basic Release Profiles and Profile Variants) below, the NewReleaseMessage shall conform to the common rules defined in Clause 5.3 (Rules for all Profiles) and rules on signalling the profile as defined in Clause 5.2 (Signalling a Specific Release Profile).

(1) All identifiers shall be globally unique. For proprietary identifiers this uniqueness shall apply in conjunction with their namespace.  

(2) The message composite shall contain the Resources for the appropriate profile as indicated in Clause 5.1 (Definition of Release Profiles).   

(3) The MessageID element shall be, in combination of the DDEX Party ID of the Message Sender, globally unique. Thus, a Message Sender shall never re-use a MessageID.

(4) All identifiers with a published syntax shall conform to that syntax.

(5) It is only permissible to communicate a UserDefinedValue attribute if a Namespace attribute is provided alongsid e it, and when the containing element contains UserDefined. 

(6) Percentages shall be provided in the interval [0,100]. 

(7) Where it is mandatory to communicate one data element for each territory for which a Deal is provided, the Message Sender shall either:

1. Communicate a single element with no TerritoryCode attribute;
2. Communicate at least one element with the IsDefault attribute set to true (this is typically set to Worldwide). No other elements may have the IsDefault attribute set to true;
3. Communicate exactly one element with the TerritoryCode attribute set to each of the territories covered by the Deal .
   

(8) Any available information on Contributors that have any of the following roles should be provided if available to the Message Sender : Adapter, Arranger , AssociatedPerformer, Author, Composer, ComposerLyricist, Librettist, Lyricist, NonLyricAuthor, SubArranger, Translator.

(9) Any data fields or composite not defined as being mandatory for a specific Release Profile may still be used by the Message Sender. The Message Recipient may, however, discard any such information at its own discretion. 

(1) All DisplayArtists must be sequenced. 

(2) To communicate "compound main artists" (e.g. "Carlos Santana feat. Eric Clapton") the following information shall be provided:

1. A DisplayArtistName showing the full name of the compound artist as it should be displayed.
   

2. A DisplayArtist composite for each of the artists that make up the compound artist.
   

   1. The main artist (in the example above Carlos Santana) shall have a DisplayArtistRole of MainArtist.
      

   2. Additional artists (in the example above Eric Claption) may not have a DisplayArtistRole of MainArtist.
      

(3) It is also permissible to communicate a compound display artist name ("John & Paul") in the DisplayArtist or Contributor composite should the Message Sender 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.

(4) For each SoundRecording and Video, a DisplayTitle and a DisplayTitleText shall be provided as follows to communicate the title as the Release Creator suggests it should be shown to consumers: 

1. A DisplayTitleText shall be communicated containing, in a single string, the title plus any available sub-title information;
   
2. A  DisplayTitle shall be communicated with the main title in the TitleText sub-element and the sub-title or version title information in the SubTitle element. Sub-title or version title information shall be removed from the TitleText and SubTitle elements alongside any characters that separate the TitleText and SubTitle (such as parentheses);   
   
3. Further titles may be provided in the AdditionalTitle composite where main title and sub/version title information shall be separated as in the DisplayTitle composite;
   
4. If a title of a SoundRecording or Video contains sub-title or version title information, but the Release Creator wishes the sub/version title information not to be shown to consumers, the Release Creator shall provide:
   
   1. A DisplayTitleText without the sub/version title information;
      
   2. A DisplayTitle without the sub/version title information; and
      
   3. An AdditionalTitle composite of type ReferenceTitle that does contain the sub/version title information to aid the Message Recipient in managing its catalog of SoundRecordings and Videos.
      

(5) For linking Releases and Resources:  

1. Each main Release shall have at least one ResourceGroup;
   
2. If the Primary Resources of a Release are to be grouped in multiple sets, two (or more) second-level ResourceGroups shall be provided. Each of these shall have a ResourceGroupType of either Side, Component, ComponentRelease, ReleaseComponent or MultiPartWork. The last three values are only valid if used in a message conformant with relevant Variants defined in Clause 5.5 below. Each of these ResourceGroups may contain further ResourceGroups;
   

3. R esourceGroups of type Component, ComponentRelease, Side or MultiWorkPart shall be sequenced in the context of their immediate parent ResourceGroup;
   

4.  Primary Resources (even if there is only one) shall be sequenced in their ResourceGroupContentItem in the context of their parent ResourceGroup;
   

5. Sequence numbers typically start with 1 (but do not have to) and shall increase monotonically, typically by 1 (other increments are also allowed). No duplicates are allowed;
   

6. There is only one sequence within a ResourceGroup. ResourceGroups and ResourceGroupContentItems are both numbered within this sequence;

7. Secondary Resources (e.g. cover images) content items shall not be sequenced;
   

8. FrontCoverImages, if included, shall be linked from the top-level ResourceGroup's LinkedReleaseResourceReference  .
   

9. Video screen captures, if included, shall be linked from the ResourceGroupContentItem of the Resource they represent by a LinkedReleaseResourceReference element with a LinkDescription of VideoScreenCapture.
   

(6) If a Cue is provided either a start time or a duration shall be provided.

(1) Any main Release intended for consumers shall be identified by either a GRid or by an ICPN  or by a ProprietaryID. Other identifiers may also be provided.

(2) TrackReleases consumption shall be identified by either a GRid, ICPN or by a ProprietaryID.

(3) If a Message Sender is considering the use of an ISRC as an identifier for a TrackRelease, it shall be communicated as a ProprietaryID.

(4) TrackReleases should be identified with an identifier unique to the content and the context (i.e. the main Release it has been taken from).

This can be achieved by, for instance, concatenating the ISRC identifying the TrackRelease's Sound Recording and the ICPN of the album Release.

(5) There needs to be a Label for each territory for which a deal is provided.

(6) A CLine may be communicated where applicable. If a CLine is provided, the recipient shall ingest it.

(7) At least one ReleaseDate or OriginalReleaseDate (the former is preferred) shall be provided for the Release if available to the Message Sender.

(8) A ResourceGroup of type Side shall only be provided for Releases that may (also) be available with a UseType of PurchaseAsPhysicalProduct. For all other Releases, the only allowed ResourceGroupTypes are Component and  MultiWorkPart .

(1) Primary Resources that are eligible for an ISRC shall be identified by an ISRC.

(2) Secondary Resources shall be identified by a ProprietaryId.  

(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.

(4) For each Resource, the sender shall provide any identifier for any underlying Musical Work (preferably an ISWC), that it has reasonable access to. 

(5) Information about Composers, Lyricists, ComposerLyricists and Adapters should be provided in the Contributor composite for each Primary Resource, if available.

(6) If a Party is playing multiple roles in 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.   

(7) A FirstPublicationDate should be provided for each Primary Resource if available to the Message Sender.

(8) To indicate that a Resource is a pre-order incentive track on a Release, the respective attributes in the relevant ResourceGroupContentItem shall be used. The same applies to instant gratification tracks.

(1) Resource Availability

When communicating a Release for which no pre-order Deal is available, the Message Sender shall ensure that for all Resources a Resource File is communicated to the Message Recipient before 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, sufficiently well before the Release is to "go live" to allow the Message Recipient to meet the "go live" date.

It is, however, preferred, that all Resources are communicated together (if possible).

(2) Resource Availability (Pre-order Releases)

When communicating a Release for which a pre-order Deal is available, the Message Sender shall ensure that for all Resources a Resource File is communicated to the Message Recipient before it is to be made available to consumers as part of the Release.

For the avoidance of doubt, it is sufficient, that the Resource is communicated via a NewReleaseMessage, sufficiently well before it is to "go live" to allow the Message Recipient to meet the "go live" date.

It is, however, preferred, that all Resources of the Release are communicated together (if possible).

(3) Signalling Resource Availability

1. When communicating a Resource File, the Message Sender shall include a TechnicalResourceDetails composite in the relevant Resource composite in the NewReleaseMessage. Where a Resource File is not present, no TechnicalResourceDetails composite may be present either. 
   When updating Resource information, the Message Sender is not obliged to re-send Resource Files (unless TechnicalResourceDetails are updated).
2. 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) Primary and Secondary Resources

1. If the Message Sender needs to update one (or more) primary Resource File(s), all primary Resource Files must be updated in accordance with Clause 5.3.3.2. This does not mean that any secondary Resource File needs to be updated.
2. If the Message Sender needs to update one (or more) secondary Resource File(s), all secondary Resource Files must be updated in accordance with this Clause 5.3.3.2. This does not mean that any primary Resource File needs to be updated.
3. In the context of a pre-order Release, the term "all" in the above sentences is to be understood as all Resources that are (or are to be made) available. This may well be a subset of the complete set.

(1) There shall only be one ResourceGroup in the main Release.

(2) The ResourceGroup shall only contain one ResourceGroupContentItem composite.

(3) The  ResourceGroupContentItem  shall only contain:

1. One ReleaseResourceReference pointing to the Primary Resource; and
   

2. One LinkedReleaseResourceReference pointing to an Image of type FrontCoverImage or VideoScreenCapture.
   

(4) A ResourceRightsController providing information on the company administering the rights of a SoundRecording, Video or other Resource may be provided with:

1. A RightsControllerPartyReference to the Party composite that describes the rights controller;

2. The list of Territorys that identify the territorial reach of the ownership (or claim thereof);
   

3. The RightsControllerRole;
   

4. A StartDate and/or EndDate if known; and
   

5. A RightSharePercentage if known.
   

(1) Primary Resources shall be identified with a ProprietaryId or an ISRC.

(2) There shall only be one ResourceGroup in the main Release.

(3) The  ResourceGroupContentItem  shall only contain:

1. One ReleaseResourceReference pointing to the Primary Resource; and 

2. One LinkedReleaseResourceReference pointing to an Image of type FrontCoverImage (if a Secondary Resource is provided).
   

(4) A RelatedRelease of type IsReleaseFromRe lease shall be provided if such a Release exists and the Message Sender has reasonable access to it.

(1) Primary Resources shall be identified with an  ISRC (if eligible) or by a ProprietaryId.>

(2) Each Primary Resources may be chaptered by including a VideoChapterReference:

1. Each Chapter item shall have a ChapterId  

2. Each Chapter shall have a StartTime indicating the Chapter start time on the Video; and
   

3. Each Chapter item may have a RepresentativeImageReference which references the ScreenCaptureImage resource representing that Chapter;
   

(3) Each primary Resource of type LongFormMusicalWorkVideo or ConcertVideo shall contain a VideoCueSheetReference or a ReasonForCueSheetAbsence.

(4)  Cues, when provided, shall meet these requirements:

1. Each Cue shall have a StartTime or Duration;
   

2. Each Cue shall contain an identifier of type ISRC or ISWC;
   

3. Each Cue shall contain at least one Contributor; and
   

4. Each Cue that is identified by an  ISRC  shall contain a PLine  .
   

(5) All other primary Resources may have a Cue.

(6) If the ReleaseType is FeatureFilm the Release shall contain an Image of type Poster.

(1) The NewReleaseMessage shall contain exactly one SoundRecording, classified in accordance with Clause 4.1 as a Primary Resource that is directly referenced from the Release via the ResourceGroup element (the "mix").

(2) The NewReleaseMessage shall contain at least two SoundRecordings "classified in accordance with Clause 4.1" as a Secondary Resource that are not directly referenced from the Release via the ResourceGroup element (the "mix components").

(3) These Secondary Resources shall have the IsSupplemental flag set to "true".

(4) The mix component shall be referenced, together with a StartPoint and DurationUsed, from the mix by a RelatedResource of type HasContentFrom.

(5) Each mix component shall be pointed to from the mix.

(6) Notwithstanding the rules on the identification of secondary Resources elsewhere, mix component Sound Recordings shall be identified with an ISRC. There is no requirement to identify them with a ProprietaryId.

(1) At least one Contributor with one of the following role codes shall be provided: NonLyricAuthor, Actor, VoiceActor or Narrator. If no Contributor with the aforementioned roles can be provided, a suitable alternative role (e.g. Artist) shall be used.

(1) The Main Release composite of a Boxed Set Release shall contain at least two ResourceGroups of type ReleaseComponent that do not represent the full Boxed Set.

(2) Each of these ResourceGroups shall meet the requirements laid out in Clauses 5.1.2 and 5.3 for their relevant profile and may contain further ResourceGroups as needed.

(3) The identifier of the "component" Release s that make up the Boxed Set Release shall be placed into the ReleaseId composite of the relevant ResourceGroup.

(1) This profile variant may only be used for Releases containing at least one Musical Work that comprises more than one "segment".

(2) Each of these multi-segmented Works shall be grouped using a ResourceGroup that follows the following rules:

1. A logical grouping of a multi-segmented Work shall be represented by a ResourceGroup of type MultiWorkPart;
   
2. ResourceGroups of type  MultiWorkPart shall contain at least two ResourceGroupContentItems;
   
3. The only exception to the above rule is a ResourceGroup of type  MultiWorkPart that is split over the boundary of a parent ResourceGroup. In this case it is allowed to have a ResourceGroup of type  MultiWorkPart containing just one ResourceGroupContentItem if, and only if, there is a ResourceGroup of type MultiWorkPart at the same nesting level immediately preceding or following it, that describes the same Work;   
4. It is permitted to combine ResourceGroups of type  MultiWorkPart with ResourceGroups of other types within the same Release; and  
5. If combining ResourceGroups of type  MultiWorkPart with ResourceGroups of other types within the same Release, the ResourceGroups of type  MultiWorkPart should be nested inside the ResourceGroups of other types.
   

(3) Each of these multi-segmented Works shall carry title elements a follows:

1. Each SoundRecording or Video that is part of a multi-segmented Work shall carry, in addition to the DisplayTitle and DisplayTitleText (see Clause 5.3.1.2 Item 4 ) an AdditionalTitle of type FormalTitle;
   
2. An AdditionalTitle of type GroupingTitle denoting the parent of each SoundRecording or Video may be communicated if the SoundRecording is a part of a multi-segmented Work;
   
3. Each ResourceGroup that contains more than one SoundRecording or Video of the same multi-segmented Work shall carry a DisplayTitle and/or DisplayTitleText of the segment in accordance with  Clause 5.3.1.2 Item 4 ;
   
4. Each ResourceGroup that contains more than one SoundRecording or Video of the same multi-segmented Work shall also carry an an AdditionalTitle of type FormalTitle if the Message Sender considers the DisplayTitle or DisplayTitleText to not be the full formal title of the segment;  
5. Such AdditionalTitles of type FormalTitle should include as much Information as possible. The precise syntax of the FormalTitle s is left to the Message Sender;
   
6. Message Recipients should ingest AdditionalTitles of type FormalTitle and use it for catalogue management and search, but to use the DisplayTitle and/or DisplayTitleText for display purposes; and
   
7. The above rules on titles may and shall also be applied to other ResourceTypes where necessary.