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 messages is the communication of Release details, including information about their parts, i.e. resources (such as sound recording or videos).

Such descriptions can, however, vary between different uses. For instance, the description of a Release that contains a single video ringtone track would differ greatly from the description of a Release representing a digital equivalent of a 10-track pop album with previews.

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”. This standard defines a set of profiles that define how to use Version 4 of the Electronic Release Notification Message Suite Standard to express the most common types of Releases.

2 Scope

2.1 Introduction

This standard defines a number of Release Profiles for common Release Types for communication in version 4 of the Electronic Release Notification Message Suite Standard (ERN). The profiles are provided in two forms: A summary of the differences between each of the Release Profiles and the relevant “full” standard, and, through sample XML code.

This document also contains information on how to determine to what extent software is conformant to this standard in the form of conformance weightings. This information is provided as shown below and needs to be read in conjunction with the relevant DDEX Conformance Standard (see Section 3).

Conformance Weighting: ...

Complete and valid sample XML files supporting these Release Profiles are available for download from http://kb.ddex.net.

2.2 Organisation of the Document

This standard has five Clauses and one Annex. The first four clauses provide an introduction, the scope, the normative references that are an integral part of this standard and the core definitions used herein.

The fifth clause defines a number of Release Profiles, including their variants and how they are to be communicated in a NewReleaseMessage.

Annex A provides a link to a set of sample messages.

2.3 Release Notes (informative)

Version 2.0 of the Release Profiles as created specifically for ERN in Version 4.0.

Version 2.1 updated the requirements for the identification of TrackReleases.

3 Normative References

3 Normative References

The following normative documents contain provisions which, when referenced 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.

Note: the provisions within this standard are specific to the above-mentioned standard. However, users of 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.

Users should take special notice of the definitions, abbreviations and conformance rules used/defined in these standards, which also apply to this standard.

4 Nomenclature

4.1 Definitions

For the purpose of this standard, the following definitions apply:

Primary Resource

A Resource that is a main Resource of a Release. A change in a Primary Resource typically requires a new Release Identifier, whereas change in a Secondary Resource does not.

All Resources that are referenced in a ReleaseResourceReference composite in a NewReleaseMessage are Primary Resources for that Release.

Release

A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.

Release Creator

Release Creator is an organisation which is the owner of copyrights in sound and/or music audiovisual recordings and/or exclusive licensees of copyrights in sound and/or music audiovisual recordings.

Main Release

A Release, communicated in a Release notification that represents the main purpose for sending the NewReleaseMessage. When communicating an album, the Main Release would be said Album Release. A typical NewReleaseMessage contains, besides the Main Release, one or more Track Releases.

Track Release

A Release, communicated in a Release notification that does not represent the main purpose for sending the NewReleaseMessage. When communicating a 10-track album, a typical NewReleaseMessage would contain, besides the Main Release, ten Track Releases (i.e. one for each sound recording that together make up the album).

Secondary Resource

A Resource that is not a main Resource of a Release. It supports the Primary Resources (examples are lyrics, cover art etc). A change in a Primary Resource typically requires a new Release Identifier, whereas change in a Secondary Resource does not.

All Resources that are referenced in a LinkedReleaseResourceReference composite in a NewReleaseMessage are Secondary Resources for that Release.

4.2 Nomenclature

The following 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 has to be included in the relevant Profile.

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

5 Release Profiles

5.1 Defintion of Release Profiles

5.1.1 Introduction

The Release Profiles defined in this Standard is a subset of the descriptions for Releases, including their components and the order/grouping of such resources that can be expressed with the NewReleaseMessage defined in the Electronic Release Notification Message Suite Standard. A Release Profile comprises of exactly one Basic Release Profile combined with none, one or more Profile Variants.

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

1 SoundRecordingeither of type MusicalWork-SoundRecording or NonMusicalWork-SoundRecording or SpokenWord-SoundRecording

0-1 Image of type FrontCoverImage

No

7. Long-form Musical Work Video, TV or Film Release

A Release containing either a multi-chapter long form video recording or, individual films and film bundles (including TV episodes, series and seasons), plus a supporting cover image and potentially a screen capture per chapter.

1) Please note that Profile IDs do not contain any white-space characters. Spaces/new-line characters in the Profile ID column are solely to keep the table as narrow as possible. The same applies to ResourceType names used in the table.

The table below shows which ReleaseTypes may be used in which profile. Other combinations are not encouraged. <No Conformance Weighting>

Notwithstanding the above, the value UserDefined may always be communicated. <No Conformance Weighting>

It is permitted to communicate more than one ReleaseType for a Release as long as all ReleaseTypes are marked as valid in the table below. <No Conformance Weighting>

Profile

ReleaseType

Audio

Video

Mixed Media

Simple Audio

Simple Video

Ringtone

Long-form Musical Work Video, TV or Film Release

DjMix

1

Album

X

X

X

2

AlertToneRelease

X

3

Bundle

X

X

X

4

ClassicalAlbum

X

X

X

5

ClassicalDigitalBoxedSet

X

X

X

6

ClassicalMultimediaAlbum

X

7

ConcertVideo

X

X

8

DigitalBoxSetRelease

X

X

X

X

9

DjMix

X

10

Documentary

X

X

X

X

11

EBookRelease

X

X

12

EP

X

X

X

13

Episode

X

X

X

X

14

FeatureFilm

X

15

KaraokeRelease

X

X

16

LiveEventVideo

X

17

LongFormMusicalWorkVideoRelease

X

18

LongFormNonMusicalWorkVideoRelease

X

19

MaxiSingle

X

X

X

20

MiniAlbum

X

X

X

21

MultimediaAlbum

X

22

MultimediaDigitalBoxedSet

X

23

MultimediaSingle

X

24

Playlist

X

X

X

X

X

X

X

X

25

RingbackToneRelease

X

26

RingtoneRelease

X

27

Season

X

X

X

X

28

Series

X

X

X

X

29

Single

X

X

X

X

30

SingleResourceRelease

X

X

31

StemBundle

X

32

VideoAlbum

X

33

VideoMastertoneRelease

X

34

VideoSingle

X

5.2 Signalling a Specific Release Profile

5.2.1 ReleaseProfileVersionId attribute

To indicate in the NewReleaseMessage the use of a specific Profile, the ReleaseProfileVersionId attribute on the root tag of the message shall be set as defined in column 2 of the table in Clause 5.1 (Definition of Release Profiles).

For the avoidance of doubt, the above is only valid for a NewReleaseMessage in accordance with Version 4 or above of the Electronic Release Notification Message Suite Standard.

Note: ReleaseProfileVersionId may not include any white-space characters.

5.2.2ReleaseProfileVersionVariantId attribute

If the NewReleaseMessage uses of a specific Profile Variant, the ReleaseProfileVariantVersionId attribute on the root tag of the message shall be set as follows:

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Communicate a single element with no TerritoryCode attribute;

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;

Communicate exactly one element with the TerritoryCode attribute set to each of the territories covered by the Deal.

Conformance Weighting for items (7)1-3: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

5.3.1.2 For Releases and/or Resources

The following common rules shall apply to all Releases and Resources in all Profiles defined in this standard:

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

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

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

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

Conformance Weighting for items (2)1-2: 2

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

Conformance Weighting 1

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

A DisplayTitleText shall be communicated containing, in a single string, the title plus any available sub-title information;

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);

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;

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:

A DisplayTitleText without the sub/version title information;

A DisplayTitle without the sub/version title information; and

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.

Conformance Weighting for items (4)1-4: 1

(5) For linking Releases and Resources:

Each main Release shall have at least one ResourceGroup;

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;

ResourceGroups of type Component, ComponentRelease, Side orMultiWorkPart shall be sequenced in the context of their immediate parent ResourceGroup;

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

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;

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

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

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.

Conformance Weighting for items (5)1-6: 1

Conformance Weighting for items (5)7-9: 2

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

Conformance Weighting 2

5.3.1.3 For Releases

The following common rules shall apply to all Releases in all Profiles defined in this standard:

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

No Conformance Weighting

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 2

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

Conformance Weighting: 2

5.3.1.4 For Resources

The following common rules shall apply to all Resources in all Profiles defined in this standard:

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

Conformance Weighting: 2

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

Conformance Weighting: 1

(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) For each Resource, the sender shall provide any identifier for any underlying Musical Work (preferably an ISWC), that it has reasonable access to.

Conformance Weighting: 1

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

Conformance Weighting: 2

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

Conformance Weighting: 1

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

Conformance Weighting: 2

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

Conformance Weighting: 1

5.3.2 Communication of Allowed Values defined in a later version

In order to communicate any allowed values defined by DDEX later than the message format used in the communication between two business partners the following approach shall be taken:

The element shall contain the value “UserDefined”;

The UserDefinedValue attribute shall be set to the value from the later standard; and

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 DownBeaming, a term defined for Version 6.9 of the Electronic Release Notification Message Suite Standard (which does not exist at the time of writing) in a Version 4 message the following XML code shall be used:

The following rules shall apply to the Communication of Resource Files:

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

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

Conformance Weighting: 1

(3) Signalling Resource Availability

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

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.

Conformance Weighting for items (3)1 and (3)2

(4) Primary and Secondary Resources

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.

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.

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.

Conformance Weighting for items (4)1-3

(5) Optimising Resource Delivery (Informative)

The provisions of Clause 5.3.3.4 prioritise simplicity of implementation over reducing data traffic. There are, however, means to reduce the data traffic.

When a Message Recipient receives a NewReleaseMessage containing a number of TechnicalResourceDetails composite, it knows that for each TechnicalResourceDetails one resource file will be available. Assuming the Message Sender included a hash sum for the Resource File (in the TechnicalResourceDetails/File/HashSum composite), the Message Recipient can decide whether to ingest the new Resource file or whether to use the Resource file it already has received in the past. This is especially powerful when the Release delivery process is based on web services (rather than SFTP).

5.4 Rules for Basic Release Profiles

5.4.1 Simple Audio/Video Single Profiles

A Release for the Simple Audio Single or Simple Video Single Profiles shall meet the following rules in addition to the rules stipulated in Clauses 5.2 and 5.3:

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

Each Chapter item shall have a ChapterId

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

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

Conformance Weighting for items (2)1-2: 1

No Conformance Weighting for item (2)3

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

Conformance Weighting: 2

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

Each Cue shall have a StartTime or Duration;

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

Each Cue shall contain at least one Contributor; and

Each Cue that is identified by an ISRCshall contain a PLine.

Conformance Weighting for items (4)2: 1

Conformance Weighting for items (4)1, 3, 4 : 2

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

No Conformance Weighting

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

Conformance Weighting: 2

5.4.4 DjMix Release

A Release for a DjMix shall meet the following rules in addition to the rules stipulated in Clauses 5.2 and 5.3:

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

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

Conformance Weighting: 1

(7) If a message sender wishes to send DJ mixes but does not have access to the data required above, that message sender cannot use the DjMix Release Profile. Instead, such Releases can be communicated using the Audio profile.

5.5 Rules for Release Profile Variants

5.5.1 BoxedSet Variant

Notwithstanding rules expressed elsewhere in this standard a Release of any type marked as being of a BoxedSet Variant shall meet the following rules:

(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 multi-segmented Works shall be grouped using a ResourceGroup that follows the following rules:

A logical grouping of a multi-segmented Work shall be represented by a ResourceGroup of type MultiWorkPart;

ResourceGroups of type MultiWorkPart shall contain at least two ResourceGroupContentItems;

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;

It is permitted to combine ResourceGroups of type MultiWorkPart with ResourceGroups of other types within the same Release; and

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.

Conformance Weighting for items (2)1-3,5: 1

No Conformance Weighting for item (2)4

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

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;

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;

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;

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;

Such AdditionalTitles of type FormalTitle should include as much Information as possible. The precise syntax of the FormalTitles is left to the Message Sender;

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

The above rules on titles may and shall also be applied to other ResourceTypes where necessary.

Conformance Weighting for item (3)3: 1

No Conformance Weighting for items (3)1-2,4-6

Same conformance Weighting as noted above for item (3)7

The SoundRecording containing the first movement of the first concerto of Vivaldi's Four Seasons may have a FormalTitle of “Concerto for Violin and Strings in E-Major, Op. 8, No. 1, RV 296 ‘La Primavera: 1. allegro’” (while the DisplayTitle might be "Vivaldi's First Spring Movement"). The ResourceGroup that contains this SoundRecording would have a FormalTitle of “Concerto for Violin and Strings in E-Major, Op. 8, No. 1, RV 296 ‘La Primavera’” (note the absence of the "allegro" in the ResourceGroup's FormalTitle).

Table 3: Samples of structured Classical Albums (Informative)

Type of Release

Release Group structure for this Type of Release

Single Work with multiple segments

ResourceGroup representing the Release containing

ResourceGroup of type MultiWorkPart (SequenceNumber=1) representing the Work containing

ResourceGroupContentItem representing the 1st segment of the Work (SequenceNumber=1)

ResourceGroupContentItem representing the 2st segment of the Work (SequenceNumber=2)

ResourceGroupContentItem representing the 3rd segment of the Work (SequenceNumber=3)

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

ResourceGroup representing the Release containing

ResourceGroup of type MultiWorkPart (SequenceNumber=1) representing the 1st Work containing

ResourceGroupContentItem representing the 1st segment of the 1st Work (SequenceNumber=1)

ResourceGroupContentItem representing the 2nd segment of the 1st Work (SequenceNumber=2)

ResourceGroupContentItem representing the 3rd segment of the 1st Work (SequenceNumber=3)

ResourceGroup of type MultiWorkPart (SequenceNumber=2) representing the 2nd Work containing

ResourceGroupContentItem representing the 1st segment of the 2nd Work (SequenceNumber=1)

ResourceGroupContentItem representing the 2nd segment of the 2nd Work (SequenceNumber=2)

ResourceGroupContentItem representing the 3rd segment of the 2nd Work (SequenceNumber=3)

Works and “tracks” mixed (disccontaining one Work with two segments, a second Work with two segments and two extra tracks)

ResourceGroup representing the Release containing

ResourceGroup of type MultiWorkPart (SequenceNumber=1) representing the 1st Work containing

ResourceGroupContentItem representing the 1st segment of the 1st Work (SequenceNumber=1)

ResourceGroupContentItem representing the 2nd segment of the 1st Work (SequenceNumber=2)

ResourceGroup of type MultiWorkPart (SequenceNumber=2) representing the 2nd Work containing

ResourceGroupContentItem representing the 1st segment of the 2nd Work (SequenceNumber=1)

ResourceGroupContentItem representing the 2nd segment of the 2nd Work (SequenceNumber=2)

For additional information on Release IDs for TrackReleases see Track Releases.

The ReleaseId for the TrackRelease should be unique for each combination of (i) content of the TrackRelease and (ii) the main Release that the TrackRelease is communicated with. <No Conformance Weighting>

1 Primary Resource of the type prevalent in the Main Release that the Track Release is communicated with; and

No secondary resources.

The Track Release shall meet all rules defined in Clause 5.3 with their relevant conformance weightings to the extent that this is possible with the XML Schema Definition of the Track Release composite.

Notwithstanding the above, title information shall only be provided if it differs from the title information provided on the Resource referenced from the ReleaseResourceReference.

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:

The suitability or fitness of the standards for any particular purpose;

The merchantability of the standards;

The accuracy, completeness, relevance or validity of the standards; or

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.