This section of the DDEX Knowledge Base contains version 1.0 of the "Choreography for the Transfer of Catalogues between Rights Holders of Sound Recordings and other such Rights Holders"

1 Introduction

DDEX has standardised a series of Message Suite Standards that define the syntax and semantics of business metadata exchanged by members of the digital media delivery chain. Amongst these are notifications of new products, including updates, to Digital Service Providers. That standard, the Electronic Release Notification Standard (ERN), can also be used when a catalogue of Releases is transferred from one record company to another record company.This standard defines the process and Choreography for the notification of the intent of a catalogue transfer (typically from the “selling” record company to its distribution partners, or DSPs), the notification of a completed catalogue transfer (typically from the “selling” record company to its DSPs) and the provision of label copy information to the “buying” record company by the “selling” record company.The process defined herein may also be used to inform third parties such as Music Licensing Companies or chart companies about a catalogue transfer.

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 https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.

Downloads & Older Versions

Download/Print standard (PDF)

XML Schema Definition Files (ZIP)

The DDEX Data Dictionary ...

... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs

... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs

... for the Musical Work Right Share Notification Choreography Standard (MWN. Version 1.2): Message Structure and AVSs

... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs

... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs

... f or the Standard for communicating links between Resources and Musical Works (Version 1.1)

... for the Recording Data and Rights Standard (Version 1.4)

... for Release Deliveries using SFTP or Web Service (Version 1.7)

... for the Recording Information Notification (Version 1.1)

... for Work and Share Notifications

... for Works Licensing

Why are there multiple data dictionaries?

2 Scope

1.2 Scope

This standard provides a standardised means for owners of a catalogue of Resources and Releases, who are exclusive rights holders or licensees for that catalogue, to inform their Release Distributor partners (DSPs) of an impending transfer of that catalogue to another exclusive rights owner or licensee. The DSP is therewith informed to takedown the affected Releases at the specified point in time (unless they receive information from the new owner or licensee of the catalogue that they can continue to sell the Releases – this process is also defined herein).

Finally, the standard defines a uniform method for the transferring catalogue owner or licensee to provide the receiving company with detailed information about the Releases and Resources that make up the catalogue. The term “exclusive” here refers to those sound recording/Resource rights for a specific territory or set of territories.

This specification allows the transmission of information to be secured and caters for non-repudiation requirements to be met. While the location and owner of the FTP/SFTP server used for such transmission is not defined herein (this is left to be agreed by Release Creator and Release Distributor), the structure of the FTP/SFTP severs and names for files are defined by this standard. At this stage, this standard does not address issues arising from data mismatches detected during the information exchange.

2.2 Organisation of the Document

This DDEX Standard has seven clauses and two annexes. Clauses 1 and 2 provide a general introduction and the scope of this Standard. Clauses 3 to 5 give a set of normative references as well as terms, definitions and abbreviations that are used in this Standard. Clause 6 then explains the general approach taken by DDEX to message standardisation.

Clause 7 then defines the choreography before Clause 8 provides the messages used in Clause 7.

Annex A provides a list of all allowed value sets, including their allowed values and respective definitions as used in this Standard. Finally, Annex B provides the relevant XML Schema files

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: DDEX Data Dictionary Standard. Latest Version
DDEX: DDEX Party Identifier (DPID) Standard. Latest Version
DDEX: DDEX Digital Signature Standard. Latest Version
DDEX: DDEX Automated Message Exchange Protocol
DDEX: DDEX Electronic Release Notification Message Suite Standard. Latest Version
W3C: XML Schema Part 1: Structures. Second Edition. 2004
W3C: XML Schema Part 2: Data types. Second Edition. 2004

4 Terms and Definitions

Click here to expand...

Batch

A grouping of one or more DDEX Messages to be processed by the recipient together.

Catalogue

A well-defined collection of items such as rights in Musical Works, Right Shares and/or Releases.

Note that the XML tags use the spelling “catalog” instead of catalogue.

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.

Exclusive Rights Owner or Licensee

A company that is either the exclusive owner of all rights for a specific territory of all Resources within a Release or the sole licensee from an exclusive Rights Owner for sound recording/Resource rights for a The term “exclusive” here refers to those sound recording/Resource rights for a specific territory or set of territories.

Intermediary

A company that plays both roles of Release Creator (e.g. in communications to downstream Release Distributors) and Release Distributor (e.g. in communications upstream Release Creators).

Message Choreography

A series of message calls and their responses which together communicate a more comprehensive level of meaning between the two business partners.

Non-repudiation

The concept of ensuring that a party cannot repudiate, or refute, the sending or receiving of a message.

Release

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

Release Creator

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

Release Distributor

Release Distributor is an organisation, which is duly authorised by a Release Creator to offer Releases manifested in the form of Products to consumers. Release Distributors include Digital Service Providers (DSPs) and Mobile Service Providers (MSPs) as well as other organisations.

Release Family

A set of Releases that are closely related. A typical example of a Release Family is an album communicated as a Main Release plus all the Track Releases whose Resources together form the Album.

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.

Ticket ID

A unique identifier that links several Web Service Calls/Responses together.

Web Service Call

The sending of an XML document to a port/address on a web server, using HTTP or HTTPS.

5 Abbreviations

Click here to expand...

AMEP	Automated Message Exchange Protocol
ACA	Appointed Certification Agency
AVS	Allowed Value Set
BP	Business 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)
CA	Certification Agency
CT	Conformance Tester
DAW	Digital Audio Workstation
DDEX	Digital Data Exchange
DSIG	Digital Signature
DSP	Digital Service Provider (incudes Mobile Service Providers)
DSR	Digital Sales Reporting
ERN	Electronic Release Notification
FTP	File Transfer Protocol (FTP specifically includes SFTP)
GRid	Global Release Identifier
HTTP	Hypertext Transport Protocol (HTTP specifically includes HTTPS)
HTTPS	Secure Hypertext Transport Protocol
IEC	International Electrotechnical Commission (see iec.ch)
ISO	International Organisation for Standardisation (see iso.org)
MIME	Multipurpose Internet Mail Extensions
MWL	Musical Works Licensing
MWN	Musical Works Notification
MRBV	Multi-Record-Block Variant
PCA	Private Certification Agency
PDF	Portable Document Format
REST	REpresentational State Transfer
RIN	Recording Information Notification
SFTP	Secure FTP
SRBV	Single-Record-Block Variant
TIS	Territory Information System (a CISAC Standard)
TLS	Transport Layer Security
UGC	User-generated content
URL	Uniform Resource Locator
XML	eXtensible Markup Language
XSD	XML Schema Definition
W3C	World Wide Web Consortium (see w3c.org)
WS	Web Service

6 Message Design Approach (informative)

Click here to expand...

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

The data elements that are common across multiple message suites will be defined within a Baseline Schema. Individual message suites (such as the one defined by this Standard) are constructed using a combination of “local” elements (which are specific only to the message set) and common elements taken from the Baseline Schema.

Elements taken from the “Baseline Schema” have either a ddex or ddexC namespace prefix (for elements defined by DDEX) or a namespace starting with iso (for elements defined by the International Organisation for Standardisation ISO), whereas elements defined for a particular Standard have namespace prefixes specific to the particular Standard. The elements necessary for the purpose of the Catalogue Transfer Choreography Standard (as defined in this document) have the ccho namespace prefix.

The full namespace for the XML Schema document for this Standard is

http://ddex.net/xml/2011/ccho/10

The full namespaces for the relevant baseline schema files are constructed to the following schema: http://ddex.net/xml/<date>/<schema>. The applicable baseline schema files for this Standard are indicated in Annex B.

In addition to including the baseline schemas, the schema file defined by this standard includes the schema files of other DDEX standards: DDEX-AMEP and DDEX-ERNM.

W3C’s XML Schema Standard has been used to define the structure of the messages and some of the business rules. However, XML Schema alone cannot easily provide a means for complex and conditional validation but XML tools such as eXtensible Stylesheet Language Transformation (XSLT) and XPath could provide a means of developing standard validation modules for each message set.

7 Catalogue Transfer Choreography

7.1 Introduction

This clause defines the choreography for informing business partners of a catalogue transfer. The entire process comprises of three to four steps – each of which uses the same choreography, however the content of the communicated messages varies slightly.

The three mandatory steps of this choreography are:

An Exclusive Rights Owner Or Licensee who wishes to transfer a catalogue to a new rights owner or licensee, informs its Release Distributor partners. This communication is understood by the Release Distributors as a takedown notice;
The Exclusive Rights Owner Or Licensee wishing to transfer the catalogue provides the catalogue in the form of an electronic feed to the new exclusive rights owner or licensee; and
The new Exclusive Rights Owner Or Licensee informs its Release Distributor partners about the transfer. This feed shall include all new identifiers allocated by the new exclusive rights owner or licensee and may, where appropriate, contain new deals that will allow a Distribution Partner to keep the content “live” within its distribution system.

A further step is optional:

The new Exclusive Rights Owner Or Licensee informs any third parties such as Music Licensing Companies or chart companies about the transfer. This feed shall include all new identifiers allocated by the new rights owner or licensee.

This process, which is ideally completed well in advance of the actual transfer date to give all involved parties sufficient time to act upon the received information, is depicted in Figure 1 below.

Figure 1: Overall Choreography of the Catalogue Transfer Choreography Standard

Security and non-repudiation issues are addressed as specified by DDEX-AMEP.

7.2 Message Exchange

Steps 1 and 3 of the process defined in the preceding Subclause shall be executed in accordance with the ECHO standard as implemented between the relevant parties. In case where the volume of a catalogue transfer would endanger normal operations, the process described in this Subclause as depicted in Figure 2 shall be used.

Step 2 of the process defined in the preceding Subclause shall be executed in accordance with the process described in this Subclause as depicted in Figure 2.

Step 4 of the process defined in the preceding Subclause shall be executed in accordance with the ECHO standard as implemented between the relevant parties. In case where the volume of a catalogue transfer would endanger normal operations or where message exchanges have not yet been established, the process described in this Subclause as depicted in Figure 2 shall be used.

Figure 2: Using FTP to exchange Messages

The trigger to indicate that a Batch is complete is a ManifestMessage as defined in Clause 8.3 of this standard. In exceptional circumstances, such as the support of human intervention, it is permissible to use a zero-byte semaphore file to indicate the upload is complete. This semaphore has to be used instead of an XML manifest formatted in accordance with Clause 8.3. The use of such a semaphore file may trigger a flag on the recipient’s side, indicating the manual nature of the override.

The FtpAcknowledgementMessage is defined in the latest version of DDEX-AMEP.

The structure and file naming conventions are defined in the remainder of this Clause.

7.3 Batch Constraints

A catalogue transfer is communicated in a single batch.

In line with the ECHO standard, a Batch is identified by the date and time of its creation in the form YYYYMMDDhhmmssnnn with

YYYY being the year of Batch creation;
MM being the month of Batch creation;
DD being the day of Batch creation;
hh being the hour of Batch creation;
mm being the minute of Batch creation;
ss being the second of Batch creation; and
nnn being the millisecond of Batch creation.

The message sender shall make sure that the BatchId is unique.

7.4 FTP Server Organisation

Each Batch shall be placed into a separate folder of its own. The folder shall be named with the BatchId. Each Release within that Batch shall be placed into a separate folder using the ReleaseId of the Release as its name. A NewReleaseMessage for each Release shall be placed into that folder Resource files shall be placed into a subfolder called “resources/”.

The ManifestMessage, and FtpAcknowledgementMessage (if used), shall be placed into the root folder of the Batch.

Note, if possible, the ReleaseId used should be a GRid as defined in the GRid standard. However, if that is not possible, the Release Creator and Release Distributor shall mutually agree a different unique identifier.

For the avoidance of doubt, this standard supports exchanging information via FTP and/or SFTP. It is for the message sender and message recipient to agree the specific protocol to be used

7.5 File Naming Convention

The file name of the ManifestMessage for each Batch shall be the string “BatchComplete_” followed by the BatchId (as defined above) and the .xml file extension. The same file name applied to the zero-byte semaphore discussed in Clause 7.2.

The file name of the AcknowledgementMessage for each Batch shall be the string “ACK_” followed by the BatchId and the .xml file extension.

The NewReleaseMessages shall be named using the same ReleaseId as used for the enclosing folder with an .xml file extension.

7.5.1 Example of FTP Server Organisation and File Naming Convention (Informative)

The example below shows one Batch with two Releases being delivered. The Batch is not yet acknowledged.

Table 1: Example of FTP Server Organisation and File Naming Convention (Informative)

20100310130322000/	A10301A0001887532A/	A10301A0001887532A.xml
		resources/	A10301A0001887532A_T1_001.mp3
			A10301A0001887532A_T2_001.jpg
	A10301A00017EG98F/	A10301A00017EG98F.xml
		resources/	A10301A00017EG98F_T1_001.mp4
			A10301A00017EG98F_T2_002.mp3
	ACK_ 20100310130322000.xml

7.5.2 Order of Processing

The Release Distributor is expected to process Batches in sequence as indicated by the date of the batch name.

7.6 Constraints on the NewReleaseMessage

When used in the context of this standard, a NewReleaseMessage, as defined in DDEX-ERNM, shall carry a CatalogTransfer composite to indicate that the message is sent as part of a catalogue transfer.

In all communications, the NewReleaseMessage, as defined in DDEX-ERNM, shall be used in accordance with the appropriate Business and Release Profiles.

In steps 1, 2 and 4 defined in Clause 7.1, the NewReleaseMessage, as defined in DDEX-ERNM, shall not contain any Deal information.

Figure 3: CatalogTransfer composite within the NewReleasMessage

Note: The CatalogTransfer composite was specifically developed for use within this choreography. It is not part of any other DDEX message suite standard.

8 Message Definition

8.1 Introduction

The hierarchical structure of the messages is provided through indentation in the tables below. In addition to the tabular description of the message, which should always be read in conjunction with Annex A, 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 8.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 by the business partners. Rules relating to the authority of business partners to unilaterally change the Message

8.2 General Conformance Rules

8.2.1 Schema Validation

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

8.2.2 Allowed Value Lists

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

This Standard does not explicitly list allowed values. The XML Schema files – as provided in Annex B – contain the allowed values at the time of writing of this Standard. 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.

8.2.3 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 Message Recipient.

8.2.4 Schema Version Id

For messages defined directly herein the only valid value for this field is "2011/CCHO/10".

For messages defined in DDEX-AMEP, the relevant value of that standard shall be used.

8.3 Manifest Message

8.3.1 Syntax and Semantics

ccho:ManifestMessage
A Message in the CCHO DdexMessageSuite that is sent to document the FTP transfer of a batch of Messages.
Message Element					Data Type	Card	Element Description
MessageVersionId					String	1	The Version of the Message.
MessageHeader					amep:FtpMessageHeader	1	The MessageHeader for the ManifestMessage.
	MessageSender				ddexC:MessagingParty	1	A Composite containing details of the MessageSender.
		LanguageAndScriptCode			String	0-1	The Language and script for the Elements of the MessagingParty as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
		PartyId			ddexC:PartyId	1	A Composite containing details of the PartyId for the Party handling the Message. If no Namespace is given, the Identifier is a DdexPartyId (DPID). Note that DPIDs are not normally used to identify Artists, Producers or other Creators.
			Namespace		String	0-1	The Namespace of the PartyId if it belongs to a proprietary Party ID scheme. If the PartyId is a DPID, the Namespace Element must not be used. This is represented in an XML schema as an XML Attribute.
		PartyName			ddexC:PartyName	0-1	A Composite containing details of the PartyNames for the Party handling the Message.
			LanguageAndScriptCode		String	0-1	The Language and script for the Elements of the PartyName as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			FullName		ddexC:Name	1	A Composite containing the complete Name of the Party, in its normal form of presentation (e.g. John H. Smith, Acme Music Inc, A Composite containing the Beatles).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			FullNameAsciiTranscribed		String	0-1	The FullName transcribed using 7-bit ASCII code.
			FullNameIndexed		ddexC:Name	0-1	A Composite containing the complete Name of the Party in the form in which it normally appears in an alphabetic index, with the KeyName first (e.g. Smith, John H.; Beatles, A Composite containing the).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			NamesBeforeKeyName		ddexC:Name	0-1	A Composite containing the Name(s) preceding the KeyName in the FullName (and that is placed after it in a FullNameIndexed). Examples: "George" in "George Michael"; "John Fitzgerald" in "John Fitzgerald Kennedy". Not all PartyNames have a NamesBeforeKeyName (e.g. Madonna, EMI Music Inc).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			KeyName		ddexC:Name	0-1	A Composite containing the Part of a Name of the Party normally used to index an entry in an alphabetical list, such as "Smith" (in John Smith) or "Garcia Marquez" or "Madonna" or "Francis de Sales" (in Saint Francis de Sales). For persons, this normally corresponds to the "family name" or names, which in Western name forms usually comes as a surname at the end of a FullName, and in Asian name forms often at the beginning of a FullName.
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			NamesAfterKeyName		ddexC:Name	0-1	A Composite containing the Name(s) following the KeyName. Example:"Ibrahim" (in Anwar Ibrahim). This is common, e.g., in many Asian personal name forms where a FullName begins with the KeyName, which is followed by other names.
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			AbbreviatedName		ddexC:Name	0-1	A Composite containing a short version of the PartyName (e.g. for use on devices with a small display).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
		TradingName			ddexC:Name	0-1	A Composite containing a TradingName for the Party handling the Message.
			LanguageAndScriptCode		String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
	MessageRecipient				ddexC:MessagingParty	1	A Composite containing details of the MessageRecipient.
		LanguageAndScriptCode			String	0-1	The Language and script for the Elements of the MessagingParty as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
		PartyId			ddexC:PartyId	1	A Composite containing details of the PartyId for the Party handling the Message. If no Namespace is given, the Identifier is a DdexPartyId (DPID). Note that DPIDs are not normally used to identify Artists, Producers or other Creators.
			Namespace		String	0-1	The Namespace of the PartyId if it belongs to a proprietary Party ID scheme. If the PartyId is a DPID, the Namespace Element must not be used. This is represented in an XML schema as an XML Attribute.
		PartyName			ddexC:PartyName	0-1	A Composite containing details of the PartyNames for the Party handling the Message.
			LanguageAndScriptCode		String	0-1	The Language and script for the Elements of the PartyName as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			FullName		ddexC:Name	1	A Composite containing the complete Name of the Party, in its normal form of presentation (e.g. John H. Smith, Acme Music Inc, A Composite containing the Beatles).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			FullNameAsciiTranscribed		String	0-1	The FullName transcribed using 7-bit ASCII code.
			FullNameIndexed		ddexC:Name	0-1	A Composite containing the complete Name of the Party in the form in which it normally appears in an alphabetic index, with the KeyName first (e.g. Smith, John H.; Beatles, A Composite containing the).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			NamesBeforeKeyName		ddexC:Name	0-1	A Composite containing the Name(s) preceding the KeyName in the FullName (and that is placed after it in a FullNameIndexed). Examples: "George" in "George Michael"; "John Fitzgerald" in "John Fitzgerald Kennedy". Not all PartyNames have a NamesBeforeKeyName (e.g. Madonna, EMI Music Inc).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			KeyName		ddexC:Name	0-1	A Composite containing the Part of a Name of the Party normally used to index an entry in an alphabetical list, such as "Smith" (in John Smith) or "Garcia Marquez" or "Madonna" or "Francis de Sales" (in Saint Francis de Sales). For persons, this normally corresponds to the "family name" or names, which in Western name forms usually comes as a surname at the end of a FullName, and in Asian name forms often at the beginning of a FullName.
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			NamesAfterKeyName		ddexC:Name	0-1	A Composite containing the Name(s) following the KeyName. Example:"Ibrahim" (in Anwar Ibrahim). This is common, e.g., in many Asian personal name forms where a FullName begins with the KeyName, which is followed by other names.
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
			AbbreviatedName		ddexC:Name	0-1	A Composite containing a short version of the PartyName (e.g. for use on devices with a small display).
				LanguageAndScriptCode	String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
		TradingName			ddexC:Name	0-1	A Composite containing a TradingName for the Party handling the Message.
			LanguageAndScriptCode		String	0-1	The Language and script of the Name as defined in IETF RfC 4646. The default is the same as indicated for the containing composite. Language and Script are provided as lang[-scipt][-region][-variant]. This is represented in an XML schema as an XML Attribute.
	MessageCreatedDateTime				DateTime	1	The DateTime on which the Message was created (the only allowed format is ISO 8601:2004: YYYY-MM-DDThh:mm:ssTZD).
	XmlChoice					0-1	An XmlComposite corresponding to the xs:choice element in an XML document or schema.
		HashSum			ddexC:HashSum	1	A Composite containing a HashSum and information about the algorithm with which it has been generated.
			HashSum		String	1	The value of the HashSum.
			HashSumAlgorithmType		ddexC:HashSumAlgorithmType	1	A Composite containing details of the Type of HashSumAlgorithm governing the HashSum.
				Namespace	String	0-1	The Namespace of the HashSumAlgorithmType. This is represented in an XML schema as an XML Attribute.
				UserDefinedValue	String	0-1	A UserDefined value of the HashSumAlgorithmType. This is represented in an XML schema as an XML Attribute.
		Signature			ftpx/amep:Signature (ds:Signature)	1	A digital signature in accordance with DDEX-DSIG.
IsTestFlag					Boolean	1	The Flag indicating whether the Message is a TestMessage (=True) or a LiveMessage (=False).
RootDirectory					String	1	An Identifier of the root directory of all Messages in the batch communicated through the ManifestMessage.
NumberOfMessages					Integer	1	The number of Messages in the batch communicated through the ManifestMessage.
MessageInBatch					ddexC:ErnMessageInBatch	1-n	A Composite containing details of an ERN Message in the batch.
	MessageType				ErnMessageType	1	The Type of Message.
	MessageId				String	1	An Identifier of the Message.
	URL				String	1	A URL of the Message.
	IncludedReleaseId				ddexC:ReleaseId	1-n	A Composite containing details of ReleaseIds. If available, a GRid should always be used.
		IsReplaced			Boolean	0-1	The Flag indicating whether this Identifier is old and has been replaced by a new one (=True) or not (=False). The Flag may only be set to True when the new Identifier is also provided. If the Flag is not set, this Identifier is deemed to be the current one.
		GRid			String	0-1	The GRid identifying the Release. This is the preferred Element and is mandatory if a GRid is available. A GRid comprises four parts: the string "A1", followed by five alphanumeric characters, ten alphanumeric characters and and one alphanumeric character.
		ISRC			String	0-1	The ISRC (International Standard Recording Code as defined in ISO 3901) used as proxy for identification of the Release. Only applicable when the Release only contains one SoundRecording or one MusicalWorkVideo. An ISRC comprises four parts: two characters, followed by three alphanumeric characters, then two digits and five digits.
		ICPN			ddexC:ICPN	0-1	A Composite containing details of the ICPN used as proxy for identification of the Release. Only applicable when the Release is an abstraction of a complete PhysicalProduct. An ICPN comprises 12 or 13 digits, depending whether it is an EAN (13) or a UPC (12).
			IsEan		Boolean	1	The Flag indicating whether the ICPN is specifically an EAN (=True) or a UPC (=False). This is represented in an XML schema as an XML Attribute.
		CatalogNumber			ddexC:CatalogNumber	0-1	A Composite containing details of the CatalogNumber of the Release.
			Namespace		String	1	The Namespace of the CatalogNumber. This is represented in an XML schema as an XML Attribute.
		ProprietaryId			ddexC:ProprietaryId	0-n	A Composite containing details of a ProprietaryIdentifier of the Release.
			Namespace		String	1	The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.
	DeliveryType				ddexC:MessageActionType	1	A Composite containing details of the Type of action that the MessageSender applies to the Message.
		Namespace			String	0-1	The Namespace of the MessageActionType. This is represented in an XML schema as an XML Attribute.
		UserDefinedValue			String	0-1	A UserDefined value of the MessageActionType. This is represented in an XML schema as an XML Attribute.
	ProductType				ddexC:ProductType	1	A Composite containing details of the Type of a Product defining which kinds of Products are within the delivered batch. Each batch may only contain one type of Products.
		Namespace			String	0-1	The Namespace of the ProductType. This is represented in an XML schema as an XML Attribute.
		UserDefinedValue			String	0-1	A UserDefined value of the ProductType. This is represented in an XML schema as an XML Attribute.
	XmlChoice					0-1	An XmlComposite corresponding to the xs:choice element in an XML document or schema.
		HashSum			ddexC:HashSum	1	A Composite containing a HashSum of the File and information about the algorithm with which it has been generated.
			HashSum		String	1	The value of the HashSum.
			HashSumAlgorithmType		ddexC:HashSumAlgorithmType	1	A Composite containing details of the Type of HashSumAlgorithm governing the HashSum.
				Namespace	String	0-1	The Namespace of the HashSumAlgorithmType. This is represented in an XML schema as an XML Attribute.
				UserDefinedValue	String	0-1	A UserDefined value of the HashSumAlgorithmType. This is represented in an XML schema as an XML Attribute.
		Signature			ftpx/amep:Signature (ds:Signature)	1	A digital signature in accordance with DDEX-DSIG.

Annex A (normative) Allowed-value Sets

Click here to expand...

Table 2 lists all allowed value sets with their allowed values and definitions that are valid within this standard.

Table 2: Allowed-value Sets used in this Standard

Allowed-value set with its allowed values		Definition
DeliveryActionType		A Type of action requested for deliveries.
	ChangeDeliveryLimits	A DeliveryActionType that requests that the delivery of NewReleaseMessages should be continued, albeit with the new limits contained in the Message.
	RestartDeliveryWithLimits	A DeliveryActionType that requests that the delivery of NewReleaseMessages should be resumed with the limits contained in the Message.
	RestartDeliveryWithPreviousLimits	A DeliveryActionType that requests that the delivery of NewReleaseMessages should be resumed with the limits previously signalled or agreed.
	StopDelivery	A DeliveryActionType that requests that no further deliveries of NewReleaseMessages should occur until further notice.
DeliveryMessageType		A Type of delivery Message.
	NonDdexMessage	A Message which is not part of one of the DdexMessageSuites.
	Unknown	A Type of an Entity used when a sender of a DdexMessage wishes to indicate that the value within the allowed value set is unknown.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
ErnMessageType		A Type of Message in the ERN DdexMessageSuite.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
	NewReleaseMessage	A Message in the ERN MessageSuite, Main Profile, containing details of a new Release.
HashSumAlgorithmType		A Type of HashSumAlgorithm.
	MD4	The MD4 HashSumAlgorithm.
	MD5	The MD5 HashSumAlgorithm.
	SHA	The SHA HashSumAlgorithm.
	SHA1	The SHA1 HashSumAlgorithm.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
MessageActionType		A Type of action requested in a Message.
	BackCatalogDelivery	A MessageActionType that contains a delivery of one or more NewReleaseMessage(s) of back catalog Releases.
	HighPriorityDelivery	A MessageActionType that contains a delivery of one or more NewReleaseMessage(s) that should be processed with high priority.
	NewReleaseDelivery	A MessageActionType that contains a delivery of one or more NewReleaseMessage(s) containing new Releases.
	ReDelivery	A MessageActionType that contains one or more NewReleaseMessage(s) providing re-deliveries of Releases.
	TakeDown	A Flag indicating whether all Releases referred to are to be taken down. This includes that all Deals for these Releases are cancelled and that no information about the Releases should be displayed to the public any more (=True) or not (=False).
	TakeDown	A MessageActionType that contains a delivery of a take-down notice for a Release. This Message should be processed with high priority.
	TakeDown	The Flag indicating whether all Releases referred to are to be taken down by the MessageRecipient. This includes that all Deals referred to in a specific Composite are cancelled and no information about the Releases should be displayed to the end user on the DSP's website (=True) or not (=False). This Flag can be used in conjunction with a StartDate of a ValidityPeriod to indicate the point in time from which all Deals are cancelled.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
NewReleaseMessageStatus		A status of a NewReleaseMessage.
	NewReleaseMessageNotProvided	A NewReleaseMessageStatus indicating that a NewReleaseMessage is not provided.
	NewReleaseMessageProvided	A NewReleaseMessageStatus indicating that a NewReleaseMessage is provided.
OrderType		A Type of order.
	BackCatalogOrder	An OrderType in which the referenced Releases are back catalog Releases.
	ExpressOrder	An OrderType in which the referenced Releases should be procesed expeditioulsy.
	HardDiskOrder	An OrderType in which the referenced Releases have been provided on a hard disk to the MessageRecipient.
	MetadataOnlyOrder	An OrderType in which only metadata and no Resources are delivered.
	NewReleaseOrder	An OrderType in which the referenced Releases are new Releases.
	OffCycleRushOrder	An OrderType in which the referenced Releases are new Releases. Their schedule is delayed, which makes it mandatory they have a higher priority than NewReleaseOrders.
	PreOrder	An OrderType in which the referenced Releases are have been pre-ordered by the DSP.
	ReDeliveryOrder	An OrderType in which the referenced Releases are re-delivered.
	TakeDownOrder	An OrderType for a take-down of a specific Release that should be processed expeditioulsy.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
ProductType		A Type of Product.
	AudioProduct	A Product that is predominantly comprised of AudioResources (SoundRecordings or MIDIs).
	GraphicsProduct	A Product that is predominantly comprised of Images.
	MixedMediaBundleProduct	A Product that is a bundle of different types of Resources.
	MobileProduct	A Product that is predominantly comprised of Products intended to be used on MobileTelephone devices.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
	VideoProduct	A Product that is predominantly comprised of Videos.
RedeliveryReasonType		A reason for a redelivery.
	BinaryCorrupted	A RedeliveryReasonType indicating that the MessageSender has detected that a Resource received is corrupt.
	MetadataInadequate	A RedeliveryReasonType indicating that the MessageSender has detected that the metadata describing a Deal or Release (or part thereof) is inadequate.
	PackageIncomplete	A RedeliveryReasonType indicating that the MessageSender has detected that some files that made up the original delivery of the Release were not (successfully) communicated.
	ProcessingErrorAtReleaseDistributor	A RedeliveryReasonType indicating that the MessageSender has detected some processing error at the ReleaseDistributor that stopped the ReleaseDistributor from making the Release available.
	ProcessingErrorAtReleaseDistributor	A SupplyChainStatus indicating that the ReleaseDistributor has encountered a processing error with respect to the Release.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
ReleaseAvailabilityStatus		A status of the availability of a Release.
	AvailableForDSP	A ReleaseAvailabilityStatus indicating that a Release is available for a DSP.
	NotAvailableForDSP	A ReleaseAvailabilityStatus indicating that a Release is not available for a DSP.
	NotClearedForDSP	A ReleaseAvailabilityStatus indicating that a Release is not cleared for a DSP.
	NotClearedForTerritory	A ReleaseAvailabilityStatus indicating that a Release is not cleared for a Territory.
	NotYetPrepared	A ReleaseAvailabilityStatus indicating that a Release is, in principle, available for a DSP, but is still in the processing stages and will become available soon.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
ReleaseType		A Type of Release according to its content, Duration and/or number of components. Note: a ReleaseType is the form in which a ReleaseCreator anticipates offering a Release to Consumers.
	AdvertisementVideo	A Video created for specifically to promote another Video, embodying a MusicalWork.
	Album	A Release that is a digital equivalent of a physical SoundCarrier of an extended Duration, typically containing multiple Tracks of SoundRecordings. It may also contain bonus Resources.
	AlertToneRelease	A Release containing a Resource for use as an AlertTone primarily on MobileTelephones.
	Animation	An audio-visual Recording using a rapid display of a sequence of images of 2-D or 3-D artwork or model positions in order to create an illusion of movement.
	AsPerContract	A Type of an Entity used when a MessageSender wishes to indicate that the value within the allowed value set is defined by the contractual relationship between MessageSender and MessageRecipient.
	AudioClipRelease	A Release predominantly containing excerpts from SoundRecordings.
	BackCoverImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a back cover image.
	BookletBackImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a back image of a booklet.
	BookletFrontImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a front image of a booklet.
	BookletRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a booklet.
	Bundle	A Release comprising more than one Resource of different ResourceTypes. Bundles are typically used in electronic distribution.
	ConcertVideo	A Video recording of a live Performance, usually of music, before an audience.
	CorporateFilm	An audio-visual Recording made for use within a corporate entity. Examples include company-internal training videos.
	DocumentImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a document.
	Documentary	An audio-visual Recording that presents a social, political, scientific or historical subject. Documentaries include current affairs programmes, TV magazines, biographies and making of programs.
	EBookRelease	A Release typically for use as an EBook.
	Episode	A Part of a Series made available at a specific point in time. It may be that a Season or Series is not yet complete when an Episode is made available. Episodes include pilots.
	FeatureFilm	An audio-visual Recording made for initial distribution in cinemas, where it would be the main attraction of the screening, or prime-time television.
	FrontCoverImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a front cover image.
	IconRelease	A Release containing an Image Resource, that is typically used as pictogram in graphical user interfaces, to represent the Release or a Resource or Party related to the Release, and which can be selected to perform a function.
	InfomercialVideo	A Video created for specifically to promote another Video, embodying a MusicalWork.
	InteractiveBookletRelease	A Release typically for use as an InteractiveBooklet.
	KaraokeRelease	A Release typically for use in Karaoke applications.
	LiveEventVideo	An audio-visual Recording capturing an Event such as a sporting event, theatrical performances, etc.
	LogoRelease	A Release containing an Image Resource, that is typically used as a logo to represent parties associated with the Release.
	LongFormMusicalWorkVideoRelease	A Release containing typically one or more LongFormMusicalWorkVideo Resources.
	LongFormNonMusicalWorkVideoRelease	A Release containing typically one or more LongFormNonMusicalWorkVideo Resources.
	LyricSheetRelease	A Release containing typically one or more lyric sheet Resources.
	MusicalWorkBasedGameRelease	A Release containing typically one or more MusicalWorkBasedGame Resources.
	MusicalWorkClipRelease	A Release containing typically one or more MusicalWorkClip Resources.
	MusicalWorkReadalongVideoRelease	A Release containing typically one or more MusicalWorkReadalongVideo Resources.
	MusicalWorkTrailerRelease	A Release containing typically one or more MusicalWorkTrailer Resources.
	MusicalWorkVideoChapterRelease	A Release containing typically one or more MusicalWorkVideoChapter Resources.
	News	An audio-visual Recording, usually regularly scheduled, which reports current events.
	NonMusicalWorkBasedGameRelease	A Release containing typically one or more NonMusicalWorkBasedGame Resources.
	NonMusicalWorkClipRelease	A Release containing typically one or more NonMusicalWorkClip Resources.
	NonMusicalWorkReadalongVideoRelease	A Release containing typically one or more NonMusicalWorkReadalongVideo Resources.
	NonMusicalWorkTrailerRelease	A Release containing typically one or more NonMusicalWorkTrailer Resources.
	NonMusicalWorkVideoChapterRelease	A Release containing typically one or more NonMusicalWorkVideoChapter Resources.
	NonSerialAudioVisualRecording	An audio-visual Recording that is not part of a Series or Season.
	PhotographRelease	A Release containing typically one or more Photograph Image Resources.
	RingbackToneRelease	A Release containing a Resource for use as an Ringbacktone primarily on MobileTelephones.
	RingtoneRelease	A Release containing a Resource for use as an Ringtone primarily on MobileTelephones.
	ScreensaverRelease	A Release containing a Resource for use as a Screensaver.
	Season	A Set of Episodes. Typically, a Season contains all Episodes to be made available in a pre-determined time frame, which often is within a twelve-month period. It may be that a Series is not yet complete when an Season is made available.
	Series	A Set of Resources (Episodes) designed to be made available sequentially.
	SheetMusicRelease	A Release containing typically one or more Resources representing sheet music.
	ShortFormMusicalWorkVideoRelease	A Release containing typically one or more ShortFormMusicalWorkVideo Resources.
	ShortFormNonMusicalWorkVideoRelease	A Release containing typically one or more ShortFormNonMusicalWorkVideo Resources.
	Single	A Release with a short total Duration, typically containing one or two Tracks of SoundRecordings.
	SingleResourceRelease	A Release containing a single Resource.
	TrackRelease	A Release containing normally one SoundRecording.
	TrailerVideo	A Video created for specifically to promote another Video, embodying a MusicalWork.
	TrayImageRelease	A Release containing an Image Resource that, in the physical equivalent Product, is a TrayImage.
	Unknown	A Type of an Entity used when a sender of a DdexMessage wishes to indicate that the value within the allowed value set is unknown.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
	VideoAlbum	A Release typically containing multiple VideoTracks. It may also contain bonus Resources.
	VideoChapterRelease	A Release containing typically one or more LongFormNonMusicalWorkVideo Resources.
	VideoClipRelease	A Release predominantly containing excerpts from Videos.
	VideoScreenCaptureRelease	A Release containing typically one or more VideoScreenCapture Image Resources.
	VideoSingle	A Release with a short total Duration, typically containing one or two ShortFormVideos.
	VideoTrackRelease	A Release containing normally one Video.
	WallpaperRelease	A Release containing a Resource for use as a Wallpaper.
ReportFormat		A Type of Report according to its FileFormat.
	ASCII	American Standard Code for Information Interchange as defined in ISO 464.
	CSV	Comma-Separated Values as specified by IETF.
	Excel2000	Excel 2000 as defined by Microsoft.
	Excel2007	Excel 2007 as defined by Microsoft.
	Excel2010	Excel 2010 as defined by Microsoft.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
	XML	Extensible Markup Language as defined by W3C.
ReportType		A Type of Report.
	DeliveryFrequencyRequestCall	A Communication in the ERN Choreography (ECHO) regarding a change in the delivery frequency of ERN Messages.
	InformationAboutDeliveredAndAvailableReleasesCall	A Communication in the ERN Choreography (ECHO) regarding information, from a ReleaseDistributor, about an available Release.
	OrderedReleasesInQueueRequestCall	A Communication in the ERN Choreography (ECHO) regarding information about selected Releases ordered for delivery.
	RedeliveryRequestCall	A Communication in the ERN Choreography (ECHO) regarding a redelivery of Resources, Releases or ReleaseDeals.
	ReleaseAvailabilityCall	A Communication in the ERN Choreography (ECHO) regarding the availability of a Release or ReleaseDeal.
	ReleaseAvailabilityRequestCall	A Communication in the ERN Choreography (ECHO) regarding a request for the availability of a Release or ReleaseDeal.
	ReleaseStatusInformationCall	A Communication in the ERN Choreography (ECHO) regarding information, from a ReleaseDistributor, about the status of a Release.
	ReleaseStatusRequestCall	A Communication in the ERN Choreography (ECHO) regarding the request for information, from a ReleaseDistributor, about the status of a Release.
	ReleaseSupplyChainRequestCall	A Communication in the ERN Choreography (ECHO) regarding the status of a Release or ReleaseDeal in a supply chain.
	ReportDeliveryCall	A Communication in the ERN Choreography (ECHO) regarding a delivery of a report.
	ReportRequestCall	A Communication in the ERN Choreography (ECHO) regarding a report request.
	SupplyChainStatusCall	A Communication in the ERN Choreography (ECHO) regarding the status of a supply chain.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
SupplyChainStatus		A status of a Release in a supply chain.
	DeliveredToReleaseDistributor	A SupplyChainStatus indicating that a Release has been delivered to the ReleaseDistributor.
	InDeliveryToReleaseDistributor	A SupplyChainStatus indicating that a Release is currently being delivered to the ReleaseDistributor.
	InPreparationForDeliveryToReleaseDistributor	A SupplyChainStatus indicating that a Release is currently being prepared to be delivered to the ReleaseDistributor.
	OrderPlacedForReleaseDistributor	A SupplyChainStatus indicating that an order for delivery has been placed with the ReleaseCreator.
	ProcessingErrorAtReleaseCreator	A SupplyChainStatus indicating that the ReleaseCreator has encountered a processing error with respect to the Release.
	ProcessingErrorAtReleaseDistributor	A RedeliveryReasonType indicating that the MessageSender has detected some processing error at the ReleaseDistributor that stopped the ReleaseDistributor from making the Release available.
	ProcessingErrorAtReleaseDistributor	A SupplyChainStatus indicating that the ReleaseDistributor has encountered a processing error with respect to the Release.
	ReleaseMadeAvailableToConsumers	A SupplyChainStatus indicating that a Release has been made available to Consumers.
	ReleaseNotAvailable	A SupplyChainStatus indicating that a Release is currently not available from the ReleaseCreator.
	ReleaseReceivedByReleaseDistributor	A SupplyChainStatus indicating that a Release has been received by the ReleaseDistributor.
	ReleaseStagedForPublication	A SupplyChainStatus indicating that a Release has been staged for publication by the ReleaseCreator.
	SuccessfullyIngestedByReleaseDistributor	A SupplyChainStatus indicating that a Release has been successfully ingested by the ReleaseDistributor.
	UserDefined	A Type of an Entity which is defined by a sender of a DdexMessage in a manner acceptable to its recipient.
TerritoryCode		A code representing a Territory. This includes ISO 3166-1 two-letter codes plus a code for Worldwide.
	Worldwide	A Place including all Territories on Earth.
WsMessageStatus		A status of a WsMessage.
	BackendProcessingError	A status indicating that the received WsMessage caused a backend processing error when evaluated or acted on.
	NoValidMessageReceived	A status indicating that the received WsMessage was either not received successfully or is a not valid XML.
	ValidMessageQueuedForProcessing	A status indicating that the received WsMessage was received successfully, is a valid XML file and has been queued for processing.
	ValidMessageReceived	A status indicating that the received WsMessage was received successfully and is a valid XML file.

Annex B (normative) XML Schema Definition Files

Click here to expand...

This Annex contains a the various XML Schema files required for creating and validating messages created in conformance with Version 1.1 of the ERN Choreography Standard. The files can be downloaded here.

Evaluation Licence for DDEX Standards

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

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

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

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

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