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.1 of the "Business Profiles for Common Deal 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 thirteen Release Profiles that define how to use the Electronic Release Notification Message Suite Standard to express the most common types of Releases. This is the second edition of Version 1.0 of the Release Profile Standard for Common Release Types. It adds support for Classical Releases by replacing the “Simple Digital Classical Audio Album” with a more complete “Classical Audio Album”.

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.


 

 

Essential Reading

Download Standard  (PDF)

Download XML Samples (ZIP)

Older versions of this standard can be accessed here.

2 Scope

 

 2.1 Introduction
This standard defines the Business Profiles for common Types of commercial exploitations of Releases as part of delivery of Releases using the Electronic Release Notification Message Suite Standard. The Business Profiles are provided in two forms: A summary of the differences between this Business Profile and relevant “full” standard and sample XML code.

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

 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-∞” means that any number (i.e. either none, one or more) of elements may be included in the relevant Profile; and
  •  “1-∞” 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 four clauses and two Annexes.

Clauses 1 and 2 provide an introduction and scope as well as defining core terms. Clause 3 then defines the Business Profiles covered by this standard. Its components, and how they are to be communicated is then defined in Clause 4.

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

 

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

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 Business 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.1 provides an update that allows datetimes to be used - instead of dates - in all aspects of a Deal.

Version 1.3 updates the mechanism by which global, territorial and partial take-downs/losses of rights are handled. It also introduced a new way for Release Creators to ask that a Release Distributor purges a Release from its database. Version 1.3 also adds conformance weightings.

Version 1.2 adds support for generic streaming profiles and  clarifies the situation regarding streaming of albums. Version 2.1 also clarifies the communication of Ringtones and Mobile products as well as physical products. It also specifies that TIS codes shall not be used for Release deliveries and that pricing information should not be used for streaming and subscription services. Version 1.2 also simplifies the handling of take-downs by deprecating the AllDealsCancelled flag and clarifies communication of instant-gratification deals.

Finally, version 1.2 defines how to communicate Releases to charting companies.

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

3 Definition of Business profiles

 Click here to expand...

The Business Profile defined herein is a subset of the descriptions for commercial exploitations, to be used in Release Notifications (i.e. in a NewReleaseMessage defined in the Electronic Release Notification Message Suite Standard) and communications regarding musical work licences (i.e. in messages defined in Musical Works Licensing Message Suite Standard), and how to report sales for Releases distributed in accordance with such exploitation types (in a sales report message defined in Sales Reporting Message Suite Standard). The differences are described in Table 1.

Each of the lines of the table defines one Business Profile. Further details of these are then provided, for each of them, in the remainder of Clause 4.

Most Business Profiles defined in this standard do not normally make use of UserInterfaceType and DistributionChannelType. However, if they are communicated they will need to be adhered to by the MessageRecipient. This is indicated with a “Normally not used” in this table. The XML samples do not show their use in such cases.

Table 1 — Business Profiles defined in this Standard

Business Profile

Name and description

Core allowed value sets describing the Business Profile

Commercial-ModelType

Use Type

User-InterfaceType

Distribution-ChannelType

Technical Instantiation

1. Generic Download Service

Consumers can download content via the internet and keep the Releases with no limitation. This profile makes no commercial distinction between DRM-protected and Non-protected versions of the service.

PayAs-YouGoModel

Permanent–Download

Normally not used

Normally not used

Not to be used

2. DRM-Protected Download Service

Consumers can download content via the internet and keep the DRM-protected Releases with no limitation.

PayAs-YouGoModel

Permanent–Download

Normally not used

Normally not used

DrmEnforced

3. Non-Protected Download Service

Consumers can download content via the internet and keep the non-protected Releases with no limitation.

PayAs-YouGoModel

Permanent–Download

Normally not used

Normally not used

Not-DrmEnforced

4. Ad-Supported Download Service

Consumers can download content via the internet and keep the  Releases with no limitation. This profile makes no commercial distinction between DRM-protected and Non-protected versions of the service. Payments are funded through advertisements.

Advertisement-SupportedModel

Permanent–Download

Normally not used

Normally not used

Not to be used

5. DRM-Protected Ad-Supported Download Service

Consumers can download content via the internet and keep the DRM-protected Releases with no limitation. Payments are funded through advertisements.

Advertisement-SupportedModel

Permanent–Download

Normally not used

Normally not used

DrmEnforced

6. Non-Protected Ad-Supported Download Service

Consumers can download content via the internet and keep the Non-protected Releases with no limitation. Payments are funded through advertisements.

Advertisement-SupportedModel

Permanent–Download

Normally not used

Normally not used

Not-DrmEnforced

7. Tethered Download Service

Consumers can download content via the internet and keep the Releases as long as a subscription is kept.

Subscription-Model

Conditional–Download

Normally not used

Normally not used

Not to be used

8. Ad-Supported Tethered Download Service

Consumers can download content via the internet and keep the Releases as long as a subscription is kept. Payments are funded through advertisements.

Advertisement-SupportedModel

Conditional–Download

Normally not used

Normally not used

Not to be used

9. Interactive Subscription Streaming Service

Consumers subscribe to a service where they can interactively stream content from a large repository of content. Payment is received via subscription fee.

Subscription-Model

OnDemand Stream

Normally not used

Normally not used

Not to be used

10. Interactive Ad-Supported Streaming Service

Consumers subscribe to a service where they can interactively stream content from a large repository of content. Payment is received via advertisement.

Advertisement-SupportedModel

OnDemand Stream

Normally not used

Normally not used

Not to be used

11. Non-Interactive Subscription Streaming Service [1]

Consumers can listen to pre-programmed (often algorithmically generated) stream of music with no interactivity beyond start/pause/stop/skip. Payment is received via subscription fee.

Subscription-Model

Non-Interactive Stream

Normally not used

Normally not used

Not to be used

12. Non-Interactive Subscription Streaming Service On Device

Consumers can listen to pre-programmed (often algorithmically generated) stream of music with no interactivity beyond start/pause/stop/skip. Payment is received as part of a device purchase or rental.

DeviceFee-Model

Non-Interactive Stream

Normally not used

Normally not used

Not to be used

13. Non-Interactive Ad-Supported Streaming Service[2]

Consumers can listens to pre-programmed (often algorithmically generated) stream of music with no interactivity beyond start/pause/stop/skip. Payment is received via advertisement.

Advertisement-SupportedModel

NonInteractive-Stream

Normally not used

Normally not used

Not to be used

14. Kiosk Service

Consumers can access a physical Kiosk and download content from there. They can then keep the Releases.

PayAsYouGo-Model

Permanent–Download

Kiosk

Not to be used

Not to be used

15. Ringtones And Mobile Service

Consumers can access content as Ringtones on their mobile phones. This also includes other "Mobile Products" such as Wallpaper Releases.

PayAsYouGo-Model

Any combination of: UseAs*-Tone for Releases that are provided by the ReleaseCreator "raw" (i.e. not specifically created as a mobile Release) or any Stream or Download UseTypes for Releases that are created by the Release Creator specifically as a mobile product.

Normally not used

Normally not used

Not to be used

16. Rights Claims On User Generated Content

Consumers may upload the content but the label asserts a rights claim and the related RightsClaimPolicy and WebPolicy (if provided) must be applied by the DSP.

RightsClaim-Model

Any combination of: UserMake-Available*

Normally not used

Normally not used

Not to be used

17. Purchase As Physical Product

Consumers may purchase the release in the form of a physical product. This includes "Direct-to-consumer" services.

The Purchase As Physical Product Business Profile is typically combined with the Physical Release Structure defined in the relevant Release Profile.

PayAsYouGo-Model

Purchase-AsPhysical-Product

Normally not used

Normally not used

Not to be used

18. Generic Ad-Supported Streaming Service

Consumers subscribe to a service where they can  stream content from a large repository of content. Payment is received via advertisement.

Advertisement-SupportedModel

Stream

Normally not used

Normally not used

Not to be used

19. Generic Subscription Streaming Service

Consumers subscribe to a service where they can  stream content from a large repository of content. Payment is received via subscription fee.

SubscriptionModel

Stream

Normally not used

Normally not used

Not to be used

20. Generic PayAsYouGo Streaming Service

Consumers  stream content from a large repository of content. Payment is made for each individual stream.

PayAsYouGoModel

Stream

Normally not used

Normally not used

Not to be used



[1] Also known as Subscriber Web Radio

[2] Also known as Ad-supported Web Radio

 

4 Communication of Business Profiles in Release Notifications

 4.1 Signalling a Specific Business Profile

 To indicate in the NewRelaseMessage the use of a specific Profile, the BusinessProfileVersionId attribute on the root tag of the message shall be set as follows:
CommonDealTypes/131/xxx

With “xxx” being the name of the Profile as defined in bold face in column 1 of Table 1 without any space or dash characters. For example, a NewReleseMessage in accordance with the Non-interactive Subscription Streaming profile defined herein shall have the BusinessProfileVersionId attribute set to

CommonDealTypes/131/NoninteractiveSubscriptionStreaming

Where the NewReleaseMessage includes deals covering more than one business profile the multiple profiles shall be indicated in the BusinessProfileVersionId field separated by a single space:

BusinessProfileVersionId="CommonDealTypes/131/GenericDownloadService CommonDealTypes/131/AdSupportedDownloadService3

 4.2 Common Limitations of Fields for all Standards

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. This specifically applies to the attributes of the four elements listed in Table 1

In addition, these rules apply:

  1. Any information provided in the two attributes, Namespace and UserDefinedValue, may be ignored unless they are specifically allowed. <Conformance Weighting: 1>
  2. The use of TIS TerritoryCodes is not permitted when communicating TerritoryCodes. <Conformance Weighting: 1> 
  3. 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>
  4. 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. Validity periods for Deals can be communicated either with a start date and/or end date (in which case the Deal starts at midnight at the beginning of the start date end/or ends at midnight at the end of the end date) or as a start datetime and/or end datetime.  <Conformance Weighting: 1> 
  6. The same applies to ReleaseDisplayStartDateTime, TrackListingStartDateTime, CoverArtPreviewDateTime and ClipPreviewStartDateTime. <Conformance Weighting: 1>



 4.3 Description of Types of Exploitations in Release Notifications
 4.3.1 Introduction

In addition to the common rules defined in Clause 3, the following limitations on the NewReleaseMessage as defined in the Electronic Release Notification Message Suite Standard apply to the different Business Profiles defined in this standard.

The limitations expressed below all apply solely to the DealList composite within the NewReleaseMessage.

 4.3.2 Limitations of Fields for all Business Profiles

The following limitations apply to all Business Profiles defined in this standard:

  1. The use of the LanguageAndScriptCode attributes is discouraged. This rule does only apply to the Deal section of the NewReleaseMessage. <Conformance Weighting: 1>
  2. 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>
  3. deleted
  4. The use of the BulkOrderWholesalePricePerUnit element is discouraged. <Conformance Weighting: 2>
  5. The use of the RelatedReleaseOfferSet composite is discouraged. <Conformance Weighting: 1>
  6. With the exception of ‘Purchase as a Physical Product’ the use of CarrierType is discouraged. <Conformance Weighting: 1>
  7. The use of the PhysicalReturns composite is discouraged. <Conformance Weighting: 1>
  8. The use of the NumberOfProductsPerCarton element is discouraged. <Conformance Weighting: 1>
  9. Deleted. 
  10. The use of the ResourceUsage composite is discouraged. <Conformance Weighting: 1>
  11. To communicate rules that limit message recipients to show certain release aspects to consumers is not encouraged unless necessary and when both parties are able to handle them. If such information is to be provided, four dates for ReleaseDisplayStartDate, TrackListingDisplayStartDate, CoverArtDisplayStartDate and ClipPreviewStartDate must be provided. Alternatively, four datetimes can be provided: ReleaseDisplayStartDateTime, TrackListingDisplayStartDateTime, CoverArtDisplayStartDateTime and ResourceAvailabilityStartDateTime. The message sender should be aware that for DSPs that cannot handle such granular “windowing” of making release information available to consumers may have to decide to delay making the Release (or certain aspects thereof) available. <Conformance Weighting: none>
  12. It is not permitted, in a single Deal to combine generic and specific UseTypes (e.g. Stream and InteractiveStream). <Conformance Weighting: 1>
  13. It is not permitted to signal all specific sub-UseTypes (e.g. all *Stream UseTypes) defined by DDEX. In such cases the generic UseType shall be used. <Conformance Weighting: 1>

 4.3.3 Generic Download Service

A Deal for a Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2<Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.4 DRM-Protected Download Service

A Deal for a DRM-Protected Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType, UseType and TechnicalInstantiation shall be provided in accordance with Table 1<Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.5 Non-Protected Download Service

A Deal for a Non-protected Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2<Conformance Weighting noted elsewhere>
  2. CommercialModelType, UseType and TechnicalInstantiation shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.6 Ad-Supported Download Service

A Deal for a Non-protected Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged.<Conformance Weighting: 2>

 4.3.7 DRM-Protected Ad-Supported Download Service

A Deal for a DRM-Protected Ad-supported Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2<Conformance Weighting noted elsewhere>
  2. CommercialModelType, UseType and TechnicalInstantiation shall be provided in accordance with Table 1<Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.8 Non-Protected Ad-Supported Download Service

A Deal for a Non-protected Ad-supported Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType, UseType and TechnicalInstantiation shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.9 Tethered Download Service

A Deal for a Tethered Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.10 Ad-Supported Tethered Download Service

A Deal for an Ad-supported Tethered Download Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.11 Interactive Subscription Streaming Service

A Deal for an Interactive Subscription Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5.  The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Interactive Subscription Streaming Service may not be combined with a generic streaming service (Profiles 18-20 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.12 Interactive Ad-Supported Streaming Service

A Deal for an Interactive Ad-supported Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Interactive Ad-Supported Streaming Service may not be combined with a generic streaming service (Profiles 18-20 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.13 Non-Interactive Subscription Streaming Service

A Deal for a Non-interactive Subscription Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged.  <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged.  <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged.  <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.)  <Conformance Weighting: 1>
  8. The use of the Non-Interactive Subsctiption Streaming Service may not be combined with a generic streaming service (Profiles 18-20 in Table 1) in the same NewReleaseMessage.  <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged.  <Conformance Weighting: 2>

 4.3.14 Non-Interactive Subscription Streaming Service On Device

A Deal for a Non-interactive Subscription Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2.  <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1.  <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged.  <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video as the concept of "streaming an album" is meaningless (to stream all tracks of an AlbumRelease, all relevant TrackReleases need to be streamed in succession). For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release. <Conformance Weighting: 1>
  8. The use of the Non-Interactive Subscription Streaming Service may not be combined with a generic streaming service (Profiles 18-20 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.15 Non-Interactive Ad-Supported Streaming Service

A Deal for a Non-interactive Ad-supported Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Non-Interactive Ad-supported Streaming Service may not be combined with a generic streaming service (Profiles 18-20 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.16 Kiosk Service

A Deal for Kiosk Service shall be communicated as follows.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType, UseType and UserInterfaceType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the DistributionChannelType element should not be used. <Conformance Weighting: 2>
  4. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  5. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>

 4.3.17 Ringtones And Mobile Service

A Deal for a Ringtones and Mobile Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged.<Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. Ringtones and Mobile Services may only be combined with the following Release Profiles: <Conformance Weighting: 1>
    1. Profile 6 ("Ringtones") for "real tones" or
    2. Profile 7 ("MidiRingtones")  for monophonic and polyphonic ringtones

 4.3.18 Rights Claim On User Generated Content

A Deal for a Rights Claim on User Generated Content shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. A RightsClaimPolicy shall be provided. <Conformance Weighting: 1>
  4. A WebPolicy may be provided. <Conformance Weighting: 1>
  5. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  6. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  7. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  8. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>

 4.3.19 Purchase As Physical Product

A Deal for a Purchase as a Physical Product shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. The UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The CarrierType shall be provided. <Conformance Weighting: 1>
  4. The use of the CommercialModelType is discouraged. <Conformance Weighting: 2>
  5. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  6. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  7. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>

 4.3.20 Generic Ad-supported Streaming Service

A Deal for a Generic ad-supported Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Generic Ad-supported Streaming Service may not be combined with a detailed streaming service (Profiles 9-13 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.21 Generic Subscription Streaming Service

 

A Deal for a Generic Subscription Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.

  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Generic Subscription Streaming Service may not be combined with a detailed streaming service (Profiles 9-13 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.3.22 Generic PayAsYouGo Streaming Service

 

A Deal for a Generic PayAsYouGo Streaming Service shall be communicated as follows. An XML file showing which elements to use is attached to this standard.
  1. The description shall follow the rules defined in Clauses 4.1 and 4.3.2. <Conformance Weighting noted elsewhere>
  2. CommercialModelType and UseType shall be provided in accordance with Table 1. <Conformance Weighting noted elsewhere>
  3. The use of the UserInterfaceType element is discouraged. <Conformance Weighting: 2>
  4. The use of the DistributionChannelType element is discouraged. <Conformance Weighting: 2>
  5. The use of the ConsumerRentalPeriod element is discouraged. <Conformance Weighting: 2>
  6. The use of PreOrderReleaseDate and PreOrderPreviewDate composites (or their datetime counterparts) is discouraged. <Conformance Weighting: 2>
  7. The use of this Business Profile may only be used in conjunction with Release Profiles containing only one Sound Recording or Video. (For the avoidance of doubt: it is permitted to communicate a multi-track Release in the same NewReleaseMessage as a streaming Deal. However, such a streaming Deal may not reference a multi-Resource Release.) <Conformance Weighting: 1>
  8. The use of the Generic PayAsYouGo Streaming Service may not be combined with a detailed streaming service (Profiles 9-13 in Table 1) in the same NewReleaseMessage. <Conformance Weighting: 1>
  9. The use of PriceInformation is discouraged. <Conformance Weighting: 2>

 4.4 Preview Variants

 Where the business profile supports previews the, the four preview dates (ReleasePreviewStartDate, TrackListingPreviewStartDate, CoverArtPreviewStartDate and ClipPreviewStartDate) shall be provide with a date earlier than the date at which the Release becomes available to consumers. The same applies to datetime elements. <Conformance Weighting: 1>

 4.5 Pre-order Business Profile Variants
 4.5.1 Introduction

A pre-order is a product offering by which consumer purchases are permitted prior to release date.

The release may take the same form as that which is available after the pre-order period or it may have exclusive elements only available as part of the pre-order offering; during the pre-order period. It may also have tracks that are fulfilled upon purchase during the pre-order period, while the rest of the release is fulfilled on release date at the end of the pre-order period.

A pre-order can have a mix of bonus and instant gratification tracks and it is also possible for a track to be both instant gratification and bonus.

Where the business profile supports pre-orders the following patterns shall be followed.

 4.5.2 Pre-Order without Preview

Release is available for pre-order but only available for pre-view and/or fulfilment on the release date.

The pre-order deal should include the following:

  1. The PreOrderReleaseDate should carry the date that the pre-order period starts. <Conformance Weighting: 1>
  2. The PreOrderPreviewDate should carry the same date as the ValidityPeriod/StartDate to indicate that preview is only possible from the release date. The same applies to their datetime counterparts. <Conformance Weighting: 1>
  3. The content of the release should be delivered to pre-order consumers on the ValidityPeriod/StartDate or ValidityPeriod/StartDateTime<Conformance Weighting: 1>

 4.5.3 Pre-Order with Preview

Release is available for pre-order with immediate pre-view and fulfilment on the release date.

The pre-order deal should include the following:

  1. The PreOrderReleaseDate or PreOrderReleaseDateTime should carry the date that the pre-order period starts. <Conformance Weighting: 2>
  2. Deleted
  3. The content of the release should be delivered to pre-order consumers on the ValidityPeriod/StartDate or ValidityPeriod/StartDateTime<Conformance Weighting: 2>

 4.5.4 Pre-Order with Immediate Download Track (Instant Gratification)

Unable to render {include} The included page could not be found.

 4.6 Price Information

Pricing information shall be communicated via the PriceInformation composite within the Deal composite. The following rules shall be applied:
  1. PriceRangeType is meant to contain rough price band information such as “budget” or “front line”. It is not meant for sending instructions on the price to be used when offering the relevant Releases to consumers. If a DSP is contractually obliged to communicate a PriceRangeType as part of its sales reporting, PriceRangeType information should be ingested. <Conformance Weighting: 2>
  2. WholesalePricePerUnit and BulkOrderWholesalePricePerUnit contain a price that a DSP can use to determine its sales price. <Conformance Weighting: 2>

  3. WholesalePricePerUnit and BulkOrderWholesalePricePerUnit may not be combined with a PriceType. <Conformance Weighting: 1>

  4. SuggestedRetailPrice is,like the PriceRangeType, not meant to be used by the DSP to determine price. <Conformance Weighting: 2>

 4.7 Life Cycle Changes
 4.7.1 Common Rules for Life Cycle Changes

Common Rules for Life Cycle Changes are:
  1. New Deal terms received in an update NewReleaseMessage completely replace all existing Deals for the Release, effective on the MessageCreatedDate. <Conformance Weighting: 1>
  2. As such MessageSenders must always supply an explicit list of all valid Deals for each Release in each new NewReleaseMessage. If existing Deals are still valid, they must be carried over into the new message. <Conformance Weighting: 1>
  3. The EffectiveDate at the ReleaseDeal level will be deprecated. In Version 3.3 of the Release Notification Message Suite Standard this field is mandatory so shall be populated with the same date as the MessageCreatedDate to avoid confusion. <Conformance Weighting: 1>
  4. The use of the AllDealsCancelled or TakeDown flags is not permitted. <Conformance Weighting: 1>
  5. All Life Cycle Changes are communicated for a specific Release or set of Releases. <Conformance Weighting: 2>

 4.7.2 UpdateIndicator

The UpdateIndicator shall not be used by the recipient of a NewReleaseMessage to determine the way the message is ingested. Thus message senders are encouraged to always use the value OriginalMessage. <Conformance Weighting: 1>

Implementers are advised that in the future DDEX will change the cardinality of this element from [1] to [0-1] and may, at a later stage, remove the element altogether.

 4.7.3 Additional Territorial Clearances Granted

This life cycle update applies when a MessageSender wishes to extend the rights granted to the MessageRecipient on an existing Release or set of Releases to cover additional territories:
  1. The MessageSender must provide a Deal for the additional territories starting on the date the grant should be applied. The MessageRecipient should apply the grant and make the content available in the new territories in the message on the start date provided. <Conformance Weighting: 1>
  2. The territories covered by the Deals in the previous NewReleaseMessages must also be included, with an active validity period, as this original deal is already applicable in the update message. <Conformance Weighting: 1>

 4.7.4 Partial Clearance Removal

Unable to render {include} The included page could not be found.

 4.7.5 Territorial Price Change

This life cycle update applies when a MessageSender wishes to permanently change the price within one or more territories they have granted to the MessageRecipient for a release and its related content:
  1. The MessageSender shall issues a price change Deal for the territory with an open period starting on the date the price change should be applied. The MessageRecipient shall apply the price change on the start date provided. A Deal covering the existing prices shall also be supplied with an end date equal to a day before the new price start date. <Conformance Weighting: 1>
  2. Note: if such a Territorial Price Change is communicated on the date the new deal comes into effect, no “bridging” deal needs to be communicated. <Conformance Weighting: 1>

 4.7.6 Territorial Price Campaign

This life cycle update applies when a MessageSender wishes to run a price campaign for a limited period within one (or more) territories.
  1. The MessageSendershall end the following Deals:
    1. A pre-campaign deal, with the original price point, with an end date equal to the day before the campaign start date. <Conformance Weighting: 1>
    2. A campaign period deal, with the campaign price point, with a start and end date matching the campaign period. <Conformance Weighting: 1>
    3. A post-campaign deal, with the original price point, with a start date equal to the day after the campaign end date. <Conformance Weighting: 1>
  2. The MessageRecipient shall ingest them accordingly. <Conformance Weighting: 1>

Note: the pre and post campaign deals may be merged into a single deal with multiple validity periods as an XML optimisation.

 4.7.7 Territorial Takedown

Unable to render {include} The included page could not be found.

 

 

 4.8 Chart Companies

For communicating new Releases to charting companies, the NewReleaseMessage shall be used with an appropriate Release Profile. In addition:
  • No Deal shall be used. <Conformance Weighting: 1>
  • Notwithstanding rules defined in the relevant Release Profile standard, a SalesReportingProxyReleaseId may be used with a ReasonType of ChartReporting, to enable the charting company to group Releases for charting purposes. <Conformance Weighting: 1>

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 Business Profile files (defined here) and the relevant Release Profile files (defined elsewhere).

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

The Business Profile samples are named Profile_xxx.xml with xxx being the name of the Profile and variants for these are named ProfileVariant_xxx.xml.

The Lift Cycle samples are named LifeCycle_xxx.xml with xxx being the name of the life cycle stage,

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…