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 3.7 of the "Electronic Release Notification Message Suite Standard"

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a suite of messages that give a uniform mechanism to enable Release Creators (usually record companies) to inform DSPs about Releases — whether they are newly created or “back catalogue” — that are available for distribution to consumers. Such communication may include Resource-level information of may be done at Release level.

This standard also enables Release Creators to inform DSPs in a standardised way the terms and conditions under which such Releases can be made available.

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/Print standard (PDF) 

  Download/Print standard tables (ZIP)

 XML Schema Definition Files (ZIP)

 DDEX Data Dictionary...

Older versions of this standard can be accessed here .

2 Scope

 

 2.1 Introduction
The suite of messages contained in this Standard provides a mechanism for Release Providers (usually record companies) to inform their distribution partners (herein called Digital Service Providers (DSPs), including Internet Service Providers (ISPs) and Mobile Service Providers (MSPs)) about Releases that can be made available to the public as electronic Products. Such Releases can include, amongst others, Releases for mobile use, Releases for download under pay-as-you-go, advertisement-supported and subscription models and audiovisual Releases.

The messages will allow such standardised information flow about the Releases themselves (i.e. Release metadata) as well as information about the commercial terms under which such Releases can be made available.

Sending or receiving a message using this standard does not necessarily imply, however, that all legal obligations are met for the Releases to be made available.

 2.2 Organisation of the Document

This DDEX Standard has six clauses and two annexes. Clause 1 and 2 provide a general introduction and the scope of this standard. Clauses 3 and 4 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard.

Clause 5 provides a non-technical overview of the messages, including the choreography of when it is anticipated that each message will be sent and a diagrammatic representation of the content of each message. Clause 6 then specifies all elements of all messages within this Standard, and their descriptions as they appear in the DDEX Data Dictionary.

Annex A then provides a list of all allowed-value sets, including their allowed values and respective definitions as used in this Standard. The last annex to be part of this document, Annex B, provides release notes, indicating the features new to this version of Electronic Release Notification Message Suite Standard.

3 Normative References

 Click here to expand...

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.
  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • IFPI: Global Release Identifier (GRid) Standard. Latest Version
  • CISAC: Musical Work Licence Identifier (MWLI) Standard. Latest Version
  • IETF RfC 5646, Tags for Identifying Languages. Latest Version.
  • ISO 639-1988, Code for the representation of the names of languages
  • ISO 3166-1:1997 Codes for the representation of names of countries and their sub-divisions – Part 1: Country codes
  • ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC)
  • ISO 4217:2001 Codes for the representation of currencies and funds
  • ISO 7064:1983, Data Processing – Check Character Systems
  • ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times[1]
  • W3C. XML Schema Part 1: Structures. Second Edition. 2004
  • W3C. XML Schema Part 2: Datatypes. Second Edition. 2004


[1] Information on ISO 8601 can be found in Annex D of Part 2 (Datatypes Second Edition) of the XML Schema standard (http://www.w3.org/TR/xmlschema-2/#isoformats).

4 Terms and Abbreviations

 4.1 Terms and Definitions

Contractually Mandatory

An entity in a DDEX Message that has the technical cardinality of 0-1 or 0-n but that is mandatory when a DDEX message is sent in a specific commercial context.

Contractually Mandatory fields may, however, be mandatory when a DDEX message is sent in a specific commercial context. In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by Message Sender and Message Recipient.

Digital Service Provider (DSP)

A Digital Service Provider (DSP), a Party making Releases available to Consumers or other DSPs over a public Telecom network. This includes MSPs (Mobile Service Providers) and ISPs (Internet Service Providers). 

Musical Work

A Work intended to be perceivable as a combination of sounds, with or without accompanying text.

Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.

Product

A Manifestation of a Release (or another Resource) which is made available to Consumers, by sale, loan or other means. The attributes of a Release in its digital manifestation as a Product may be technical (e.g., the codec or bit rate); a mode of distribution (e.g., downloading or streaming); or a commercial term (e.g., price).

Release

A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer for the purpose of distribution to individual consumers, directly or through intermediaries. 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.

Resource

A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.

 4.2 Abbreviations

AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile
CISAC

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation
DDEX

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MIMEMultipurpose Internet Mail Extensions
MLCMusic Licensing Company
MWLMusical Works Licensing
MWNMusical Works Notification
MRBV

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification
SFTPSecure FTP
SRBV

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see w3c.org)
WSWeb Service

5 Message Overview

 5.1 Namespace

The full namespace for the XML Schema document for this Standard is
http://ddex.net/xml/ern/371

All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from ddex.net.

 5.2 Allowed-value Sets

All messages defined in this standard make intensive use of allowed-value sets. These allowed value sets are shared between all DDEX standards and DDEX provides a XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from ddex.net.

The full namespace for the XML Schema document for the allowed-value sets is

http://ddex.net/xml/avs/avs

DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued form part of this Standard. Thus the list of allowed-value sets provided Annex A contains the list of allowed-value sets valid on the data of issuance of this Standard.

 5.3 Message Choreography

Figure 2  shows the choreography of processes that the Main Profile of the Electronic Release Notification Message Suite Standard enables.


Figure 1 — Choreography of the Electronic Release Notification Message Suite

Table 1 below summarises the point in the Release cycle when each message is sent. The table also indicates who sends which message to whom and which of the messages are defined in this Standard.

Table 1 — Messages in the Electronic Release Notification Message Suite

Message Name

Initiating Event

Sender

Recipient

1

NewRelease-Message

The Release Creator decides to make a Release available to the market and collates all necessary information about the Release. This does not necessarily include information about the commercial conditions under which the Release may be made available.

Release Creator, typically a record company

DSP

The Release Creator has decided on the commercial conditions under which the Release may be made available. This Deal is in effect from the moment indicated on a “per Release” in the EffectiveDate element.

2

CatalogList-Message

The Release Creator wishes to inform a DSP (or any other party) about a catalogue it is (or may be) making available.

Release Creator, typically a record company

DSP

 5.4 Message Content Overview (informative)

Each of the messages defined in this Standard conveys a set of data elements from sender to recipient. The following diagrams show these information elements for the various messages. They allow a rapid overview of the different messages for technicians as well as for business process experts of organisations that are to implement the Standard defined herein. The data element names shown in the diagrams below are not the formal names used in the messages as the diagram is intended to provide a quick overview of the data to be provided within the messages.

The diagrams are not normative.

Figure 2 — Information content in the NewReleaseMessage (Overview)

Note that one XML Attribute, LanguageAndScriptCode, is only shown on the top-level (message) composites; it is accompanied with two further attributed to indicate a specific Release or Business Profile (not shown). This attribute is, in fact, present on all composites or elements that might benefit from being coded in different languages and/0r scripts. If placed on a composite, its value applies to all sub-elements (and, potentially, overrides a different LanguageAndScriptCode “further up”. If placed on an element its value applies only to that element. The LanguageAndScriptCode is provided in accordance with IETF RfC 4646.

Figure 3 — Information content in the NewReleaseMessage (Collections, CueSheets)

Figure 4 — Information content in the CatalogListMessage

Also note that dashed lines represent logical relationships between entities. These relationships are represented not but one entity’s metadata physically including the other entity’s metadata but by referencing — using XML Schema’s xs:ID/xs:IDREF mechanism — the linked entity. The “anchors” for these references are not listed in the diagrams below.

 5.5 Describing Audio-visual Releases (informative)

5.5.1    Series and Seasons

The support for audiovisual Releases such as TV programmes is, in many circumstances more complex than “traditional” audio-only Releases. This is because TV programmes often come in multiple instalments — sometimes called Episodes, Seasons and Series. To allow the communication of such hierarchical Releases, DDEX has developed a composite called “Collection” as it can collect one ore more individual Resources into a, for instance, “Season”. Equally, this composite can be used to collect several “Seasons” into a “Series”. This concept is shown in Figure 5 below where a company wants to declare a Series comprising one pilot programme plus two Seasons, each comprising themselves of two Episodes (blue). The company now wants to make available the pilot, Seasons 1 and 2, Episode 2 of Season 2, the entire Series and each individual Episode. Thus eight Releases are created (green). Not shown are the Deals for these Releases.

 

Figure 5 — Collections of Resources

Not shown in Figure 5 is the ability to associate a “representative image” — i.e. a static image that can be shown to the user to represent the entire collection — to each of the Collections.

5.5.2    Chapters

It should be noted that each episode itself could also be described in a Collection (of typically one item). This was made to enable splitting an episode into several parts. Such splitting of an individual Resource is, however, typically done by a process of “chaptering”. Such chapters are also described within the Collection composite. A chapter is a subset of a Resource, such as the one representing the pilot programme of the TV series shown in Figure 5. Figure 6 shows how this Resource could be split into four chapters (e.g. representing the opening scenes, the main body of the episode, the cliff hanger at the end and, finally, the closing credits).

 

Figure 6 — Chapters of a Resource

Such chapters are also useful on sound recordings, most notably concert recordings, where the clapping may need to be separated out from the actual music, and audio books. As with Figure 5, Figure 6 does not show the ability to associate a representative image with each chapter.

5.5.3    Cues

The final aspect to support audiovisual Releases lies in the ability to provide “cue sheets” to the message recipient. Cues inform about which Work or Resource is being used in a “host” Resource at which location, for how long and for what purpose.

Not shown in the diagram is the ability to directly include the cue’s metadata (title, contributors, etc.) into the cue composite.

 

Figure 7 — Cues

5.5.4    Successive Completion of Audio-Visual Releases (informative)

When making available audio-visual Releases there is a common requirement for Releases to be successively completed, i.e. a Release is created (and made available) at a point in time when not all of its constituent parts are available or even known. An example is a TV series where the Release is created, and put up for sale, when the first episode has been shown. As soon as the second episode has been broadcast, the Release is “augmented” by that second episode. This can continue until the season is “complete”.

This Standard can be employed to commutate such Releases as follows:

  • To declare an incomplete Collection, the message sender can:
  • Set the isComplete flag within the Collection composite to “false”;
  • Set the Number of Collections field within the Collection’s CollectionCollection-ReferenceList to the number of parts that would make the collection complete; this number would need to be bigger than the number of References in the Collection-CollectionReferenceList;
  • To declare an extension to a previously incomplete Collection (which remains incomplete), the message sender needs to report all parts of the Collection (i.e. old and new parts) and:
  • Set the isComplete flag within the Collection composite to “false”;
  • Set the Number of Collections field within the Collection’s CollectionCollection-ReferenceList to the number of parts that would make the collection complete; this number would need to be bigger than the number of References in the Collection-CollectionReferenceList;
  • To “declare” an extension to a previously incomplete Collection (which is now complete), the message sender needs to report all parts of the Collection (i.e. old and new parts)and:
  • Set Collection->isComplete to “true”
  • Set the Number of Collections field within the Collection’s CollectionCollection-ReferenceList to the number of References in the CollectionCollectionReference–List.

 

 

 5.6 Describing Exploitations of Releases (informative)

In DDEX Messages MessageSenders can use five allowed value sets to describe how Releases can be (or have been) exploited. They are:
  • ReleaseType
  • UseType;
  • CommercialModelType;
  • ConsumerInterfaceType; and
  • Distribution Channel Type.

The ReleaseType categorises the Release from the point of view of the ReleaseCreator. For example, a ReleaseCreator may create a Release for use as a RingbackTone on a mobile phone. This is distinct from the UseType which describes what a Consumer is allowed to do with a Release. For example, a Release created as a “normal” digital Album, might be used as a RingTone.

The third dimension, the Commercial Model type describes how Consumers pay for the Release, whether the transactions are based on subscriptions or whether the Consumer pays directly for each Release received.

The final two dimensions can be used to describe the devices on which Consumers consume (e.g. a portable device or a games console) the Releases and through what type of conduit they receive the Releases (e.g. a radio broadcast or the Internet). It is important to know that in many cases such detail will not be required and, thus, ConsumerInterfaceType and DistributionChannelType are optional fields in the messages.

 5.7 Communication of Allowed Values defined in a later Standard (informative)

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>

The XML snippet on the left is incorrect. It should be:

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

This will formally be corrected in the next version of the standard.

6 Message Definition

 6.1 Introduction

This Clause contains an overview for each of the two messages in the Electronic Release Notification Message Suite Standard in a tabular form. The full technical specification is includes the XML Schema files accompanying this standard.

The Standard comprises two messages:

  • NewReleaseMessage, a message in the Electronic Release Notification Message Suite Standard containing details of a new Release; and
  • CatalogListMessage, a Message in the Electronic Release Notification Message Suite Standard containing a list of Releases that form part of a catalogue.

The hierarchical structure of the messages is provided through indentation. On the Message Header for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName (plus a PartyId). A second example from the Message Header is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a DateTime element. All elements that have subelements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the Message Summary: the cardinality. In the case of MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more MessageAuditTrailEvents.

Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages; instead exactly one of the “branches” below the XmlChoice keyword has to be used.

In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema files, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 6.2.

Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the Standard and will need to be agreed between business partners. Rules relating to the authority of business partners to unilaterally change the Message Standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.

The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.

 6.2 General Conformance Rules

6.2.1 Schema Validation

A message is conformant to this specification only when it validates against the set of XML Schema files provided.

6.2.2 Allowed Value Lists

The allowed values are listed, defined and provided through the DDEX Data Dictionary Standard in accordance with its latest version. Other values are not possible unless by using the mechanism described below:

This Standard does not explicitly list allowed values. The XML Schema files contain the allowed values at the time of writing of this Standard (see Annex A). Some of the allowed value sets contain a provision to either use a User Defined Value instead of a DDEX-defined value (in that case the MessageSender has to select the value “UserDefined” from the AVS and provide its own value in the XML attribute “UserDefinedValue”) or to augment a DDEX-defined value (in that case the MessageSender may not select the value “UserDefined” from the AVS but shall provide its additional information in the XML attribute “UserDefinedValue”). In either case the Namespace attribute shall be used to indicate where the UserDefinedValue is defined and maintained.

6.2.3 Allowed Values for Namespace Attributes

The Namespace attributes can be used to allow message parties to use proprietary value lists.

The allowed value for the Namespace attribute which is recommended to be used is the DDEX Party Identifier of the party controlling the proprietary allowed value, as defined in, and administered in accordance with the latest version of the DDEX Party ID Standard.

6.2.4 Indicating Unknown Values

When the sender of a message is required to provide a data element but cannot do so, the following values shall be entered:

  • In fields of type xs:string: “#unknown#” ;
  • In fields of type xd:date: “9999-01-01”;
  • In fields of type xs:datetime: “9999-01-01T99:01:01”; and
  • In fields of type xs:duration: “PT99H01M01S”.

The circumstances under which such behaviour is permissible may be limited in the specific business relationship between message sender and message recipient.

6.2.5 Contractually Mandatory

The messages defined in this standard contain fields with cardinality “0-1” or “0-n”. Therefore these fields are from the standard’s point of view, optional. Such fields may, however, be mandatory when a DDEX message is sent in a specific commercial context.

In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by MessageSender and MessageRecipient.

6.2.6 On-Demand Stream

While the DistributionChannelType allowed-value set includes the OnDemandStream, this value is deprecated as it is a UseType and not a DistributionChannelType.

6.2.7 Schema Version

The only valid value for this field is "ern/371".

 6.3 Syntax and Semantics of Messages

6.3.1 NewReleaseMessage

The tabular rendering of the messages  is provided in a separate document. See the blue box here.

3.6.2 CatalogListMessage

The tabular rendering of the messages  is provided in a separate document. See the blue box here.

 

 

Annexes

 Annex A (normative) Allowed-Value Setshere to expand...

Table 2 lists all allowed value sets with their allowed values and definitions that are valid within this standard. Note, the allowed-value sets are maintained outside of this Standard and DDEX may add to the list below.

Table 2 — Allowed-Value-Sets used in the Electronic Release Notification Message Suite Standard

The Table of AVSs is provided in a separate document. See the blue box here.


 Annex B (informative) Release Notes

 

Changes between Versions 3.7 and 3.7.1

 

Version 3.7.1 provides an update that allows datetimes to be used in all aspects of a Deal.

Changes between Versions 3.6 and 3.7

The main changes in this public draft over version 3.6 are:

  • Support for TIS territory codes;
  • Support for legacy ISO country codes in all places where historic data might be communicated;
  • Enhanced support for Audiovisual content such as TV Series, Seasons and Episodes such as sequencing of Episodes and Seasons, provision of composers and other indirect ResourceContributors on Cues, communication of audiovisual duration on Release level;
  • Ability to signal how binary content (e.g. fingerprints) are coded;
  • Enhances support for mobile products (for details see Release and Resource Profiles);
  • Ability to communicate a DisplayArtistName on Resource level;
  • Additional UseTypes (for details see Release and Resource Profiles);
  • Making the MessageThreadId in the Message header optional;
  • Support for territorial title information for all Resource types;
  • Support for territorial P/C line elements;
  • Support for the current approach on how to communicate the date a release or resource was made available as documented in the relevant Release Profile;
  • Support for pre-order deals through the inclusion of a IsPreOderDeal flag;
  • Support for pre-order incentive tracks and instant gratification tracks through inclusion of a link from a Deal (specifically a Pre-order Deal) to specific resource or resorces;
  • Support for dates in the form YYYY or YYYY-MM only; and
  • Support of signalling the type of a LabelName provided through an appropriate allowed-value set.

In addition there are changes to the XML Schema that do not affect the messages created in according with these standards (e.g.: all branches of an XmlChoice element are now mandatory - but each of them remains, in effect, optional).

Changes between Versions 3.6 and 3.5

The main changes in Version 3.6 are:

  • The ability to provide multiple party ID for a party such as a recording artist;
  • Extensions to the Video composite to support video resources in multiple languages (including subtitles) and the ability to include a human readable description of a movie rating scheme;
  • Changing the cardinality of the DisplayArtist within the ReleaseDetailsByTerritory from [1..∞[ to [0..∞[ and updating the defintiion of the composite to indicate that the DisplayArtist is mandatory in the default ReleaseDetailsByTerritory but optional for all other ReleaseDetailsByTerritorys;
  • Support of various PreviewDates: ReleaseDisplayStartDate, TrackListingPreview-StartDate, CoverArtPreviewStartDate and ClipPreviewStartDate; and
  • Change of the WebPolicy to allow either a block on the content or a fine-grained policy expression to be communicated.

In addition to this, the structure of the XML Schema files has been significantly simplified; this change has, however, no impact in the structure of the messages. Similarly, version 3.6 contains a few clarifications for the use of some elements in the message.

Changes between Versions 3.5 and 3.4

The main changes in Version 3.5 are:

  • Adding a RightsClaimModel into Commercial ModelType allowed value set;
  • Adding PurchaseAsPhysicalProduct into the UseType allowed value set;
  • Adding ClassicalAlbum into the ReleaseType allowed-value set;
  • Creating a RightsControllerType for use in the NewReleaseMessages for communications to music licensing companies;
  • Add a BudgetRoyaltyRate into RoyaltyRateCalculationType allowed value set;
  • Changing the cardinality of the ArtistRole for artists from 0-∞ to 1-∞;
  • Added a ArtistDelegatedUsageRights for use in the NewReleaseMessages for communications to music licensing companies;
  • Added a ContactID composite for use in the NewReleaseMessages for communications to music licensing companies;
  • Adding ability to communicate membership with a music licensing company into the ResourceContributor composites;
  • Clarifications on the definitions of various release dates;
  • Adding an IsBackfill flag to the NewReleaseMessage;
  • Adding an IsMainRelease attribute into the Release composite;
  • Adding a GlobalReleaseDate and GlobalOriginalReleaseDate into the Release composite;
  • Adding a ReleaseDate into the ReleaseDetailsByTerritory;
  • Adding a DisplayConductor into the ReleaseDetailsByTerritory and SoundRecordingDetailsByTerritory composites for use in the NewReleaseMessages for communications to music licensing companies;
  • Adding an IsMastered flag into the SoundRecording composite;
  • Adding capability to communicate the number of featured, non-featured, contracted and non-contracted participants in the creation of a SoundRecording or Video;
  • Adding a TerritoryOfCommissioning into the SoundRecording composite; and
  • Updating the ISO code lists to reflect recent changes.

Changes between Versions 3.4 and 3.3

The main changes in version 3.4 are:

  • Simplification of the allowed value sets to communicate CommercialModelType, UseType, UserInterfaceType and DistributionChannelType. Note that some allowed values were deprecated but not yet removed from the standard; these values are marked as being “deprecated” in the data dictionary and DDEX advises that such values will be removed at a future date and therefore recommends against using them;
  • Added a uniform method to indicate that a party ID is an International Standard Name Identifier (ISNI) or DDEX Party ID (DPID);
  • Changed the cardinality of a Deal’s Effective Date to [0-1] and added clarification that this value should be set to the date the NewReleaseMessage is sent; this element will be deprecated when this standard reached version 4.0;
  • Added the ability to reference a Release from a ResourceGroup to indicate that the referenced Release contains the same content as the referencing ResourceGroup ;
  • Added SoundProcessorTypes for MidiResources and AudioCodecTypes for Sound­Recordings; and
  • Replace the UgcAccessPermissionRule with a more expressive RightsClaimPolicy(*).

Note: the change indicated with an asterisk is a non-compatible change to version 3.2. However, since the UGC feature of Version 3.2 was erroneously included in version 2.3 this change is classified as a “bug fix”.

In addition there are changes to the ddex.xsd and ddexC.xsd baseline schema files that have been implemented to support other DDEX standards but that do not impact upon version 3.3 of the Electronic Release Notification Message Suite Standard.

Changes between Versions 3.3 and 3.2

The main changes in version 3.3 are the removal of two messages, NewDealMessage and MusicalWorkInformationMessage  and the addition of a CatalogListMessage. In addition several changes to the NewReleaseMessage were made, including:

  • Ability to signal the Release Profile and Business Profile a message conforms to;
  • Update of the ISO 4217a list of currencies, including the addition of AFN, AZN, CLF, COU, CUC, GHS, MGA, MXV, RON, RSD, SDG, TMT, TRY, UYI, VEF, ZWL;
  • Update of the ISO 3166a2 list of countries, including the addition of MF;
  • Ability to communicate pre-order previews;
  • Ability to communicate Releases that do not contain Resources when being communicated (this enables, for instance “passport services”);
  • Ability to communicate container file formats such as WAV and QuickTime;
  • Ability to communicate multiple sub-titles;
  • Ability to communicate the duration of a Work or Resource used within another Resource;
  • Ability to communicate conditions under which a “user-generated-content” site may make Releases available to users;
  • Ability to reference Resources or Works in Cues that are not communicated in the same NewReleseMessage;
  • Ability to limit a Deal to a specific DistributionChannelPage (instead of a Release);
  • Ability to communicate multiple sets of PriceInformation in a ReleaseDeal;
  • Ability to communicate multiple Keywords for Creations (in Version 3.2 multiple keywords had to be communicated in a single XML tag, separated by an undefined whitespace character);
  • Ability to communicate multiple languages of performance for Video Resources;
  • Ability to communicate multiple artist web pages;
  • Ability to communicate multiple SheetMusicIDs for each SheetMusic Resource;
  • Ability to reference a SheetMusic Resource from a Release (bugfix);
  • Ability to communicate Fingerprints and ConsumerFulfilmentDates on Technical–ResourceDetail level;
  • Update TechnicalMidiDetails, TechnicalSoundRecordingDetails, TechnicalVideo-Details to enable communication about Resources that need processing by the DSP before being sold to consumers;
  • Support of the choreography to aid the exchange Catalogues (DDEX-CCHO) by adding the ability to communicate CatalogTransfer items (this element is only intended to be used in the context of that standard);
  • Various changes that support the — forthcoming — DDEX Standard for communication between Musical Licensing Companies (DDEX-MCLM-10-2011);
  • Adding of Dancer, Designer, StudioMusician and StudioPersonnel to the ArtistRoles;
  • Adding of a-law, µ-law, Adaptive Multi-Rate codec (wide and narrow band variants) and Shockwave to the AudioCodecTypes and Shockwave to the VideoCodecTypes;
  • Adding of VideoAlbum, VideoChapterRelease and VideoTrackRelease to the ReleaseType;
  • Adding of Broadcast, KioskDownload, PerformInPublic, PrivateCopy, UseAsRingbackTune to the UseTypes;
  • Changing the Cline and Plines so that the year is optional and a ClineCompany can be separately be provided;
  • Allowing to indicate that an identifier has been “replaced” by a new identifier. This applies to all identifier composites in all messages;
  • Clarified the use of the MessageThreadId in the context of metadata messages (as opposed to web service call messages);
  • Added a flag to the Resource composite that indicates that PerformerInformation is required to be provided in the message as well;
  • Ability to specify the validity period of Deals by time as well as date (using xs:datetime); and
  • Ability to communicate a human-readable description in PriceInformation composites.

In addition there are changes to the ddex.xsd and ddexC.xsd baseline schema files that have been implemented to support other DDEX standards but that do not impact upon version 3.3 of the Electronic Release Notification Message Suite Standard.

Changes Between Versions 3.2 and 3.1.12

Below please find major new features of Version 3.2 of the Electronic Release Notification Message Suite Standard Electronic Release Notification Message Suite Standard:

  • Ability to communicate physical Products in accordance with NARM UPC425 requirements;
  • Ability to communicate, especially to aggregators, a list of DistributionChannels for which a ReleaseDeal is not available;
  • Ability to include a “displaced” MusicalWorkId element on selected Resource composites;
  • Ability to communicate multiple SalesReportProxyIds (e.g. one for royalty reporting and one for chart reporting);
  • Ability to provide multiple names for each Party for allow, for instance, for different spellings and/or character sets;
  • Ability to chapter Audio Resources (e.g. for audio books, Medleys and Potrpotrris);
  • Update of the ReleaseRelationshipType list for increased support for mobile Releases;
  • Addition of QCELP to the AudioCodecTypes; and
  • Various bug fixes on data types and (obvious) mistakes in definitions.

Changes Between Versions 3.1.2 and 3.1.1

Version 3.1.2 corrected a bug that made the use of collections impossible.

Changes Between Versions 3.1.1 and 3.1

Version 3.1.1 corrects a few bugs from Version 3.1:

  • The order of the main message elements has been changed to make simple audiovisual Releases easier to ingest. The new order is: Works-Cues-Resources-Collections-Releases-Deals;
  • The PreviewDetails’ start time field has been removed from non-linear Resource types such as Images; and
  • The Duration field within the Video Resource composite has been made mandatory to align with all other linear Resource types.

In addition, version 3.1.1 provides these features above version 3.1:

  • Support for providing a rationale why a cue sheet is not provided while the provision of cue sheets is Contractually Mandatory;
  • Support for distinguishing between Deals for DRM-protected and non DRM-protected Releases, lossily coded and losslessly coded Releases, high-definition and standard definition Releases and Releases coded at different bit rates;
  • Support for distinguishing between Deals for promotional and non-proportional Release uses;
  • Support for physical distribution of Releases by providing CarrierType information (a.k.a. configurations);
  • Support for providing Deals for Release Rentals;
  • Alignment of TitleTypes with those provided in Common Works Registration process; and
  • Support for providing of details of a sales channel (e.g. its URL) through which a Release is to be distributed.

Changes Between Versions 3.1 and 3.0.1

Below please find major new features of Version 3.1 of the Electronic Release Notification Message Suite Standard:

  • Ability to handle CheSheets;
  • Ability to handle Collections, i.e. Series, Seasons, Episodes and Chapters;
  • Ability to communication Characters — as opposed to Contributors — within Video Resources, Chapters and CueSheets;
  • Ability to communicate further technical Resource metadata, especially for Video Resources such as TV programmes such as VideoDefintionType; and
  • Ability to communicate content rating codes provided by various rating agencies.

 

Messages generated in accordance with Version 3.1 of the Electronic Release Notification Message Suite Standard remain still valid when parsed against the 3.1 schema files.

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…