Skip to end of metadata
Go to start of metadata

 

This section of the DDEX Knowledge Base contains version 1.1 of the "Canadian Mechanical Licensing Choreography Standard"

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. DDEX has also standardised a two automated message exchange protocols that enable the reliable communication of DDEX messages and associated documents such as resource files, using FTP or Web Services.

This standard utilises these two aspects – message format and message exchange – for providing a uniform mechanism for Record Companies to apply for mechanical licences for physical products released into the Canadian market from a Musical Works Licensor and for such licences to be granted.

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://www.ddex.net/implementation/form.html.

2 Scope

 

 2.1 Introduction

 

This standard provides standardised means for Licensors to report sales and usages sales and usages of Products based on Releases to Licensees such as Music Rights Societies and/or Record Companies. It defines three Profiles, one using FTP/SFTP and two using Web Services as its underlying message exchange mechanism:

This standard provides 

  • A choreography for communicating licence requests (including updates), and supporting information via an FTP/SFTP server:
  • A choreography for soliciting such licence requests;
  • A choreography for communicating licences and licence refusals (including updates);
  • A choreography for accepting or rejecting granted licences; and
  • A choreography to communicating that products have been taken off the market.

While the location and owner of the FTP server is not defined herein (this is left to be agreed by Licensee and Licensor), the structure of the FTP severs and names for files are defined by this standard.

This specification allows the transmission of information be secured and caters for non-repudiation requirements to be met.

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 standard comprises nine Clauses. Clauses 1 to 4 provide an introduction to thus standard, including a scope, a list of normative references and abbreviations.

Clause 5 then introduces the general approach to messaging employed by DDEX before Clauses 6 to 77 Granularity of Licences and Right Shares define the choreographies and at what level licences are to be provided. Clause 8 then defines the sever setup for mechanical works licensing in Canada. Finally Clause 9 formally defines the FTP/SFTP server setup and the structure of the messages defined herein.

 2.3 Release Notes

Changes between Versions 1.1 and 1.0

Version 1.1 changes the choreography such that instead of one Resource bit stream is to be sent in support of a licence requests, two such files have to be provided (one full-length version and one 90s excerpt).

Version 1.1 also clarifies that the communication between Message Sender and Message Recipient can be enabled using the Secure FTP (SFTP) protocol as well as using the simple, and unsecure, FTP.

3 Normative Reference

 3 Normative References

The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.

  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • DDEX Digital Signature Standard. Latest Version
  • DDEX Automated Message Exchange Protocol Standard. Latest Version
  • DDEX Musical Work Licensing Message Suite Standard. Latest Version, potentially profiled by an appropriate DDEX Business or Release Profile standard
  • DDEX Electronic Release Notification Message Suite Standard. Latest Version
  • DDEX ERN Choreography Standard. Latest Version
  • W3C: XML Schema Part 1: Structures. Second Edition. 2004
  • W3C: XML Schema Part 2: Data types. Second Edition. 2004
  • ISO 32000-1: Document management. Portable document format. Part 1: PDF 1.7

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

Licensee

A Party to whom permission to use a Creation (e.g.: MusicalWork, Sound Recording or Release) is granted in a License Agreement.

Licensor

An Agent granting permission to use a Creation such a MusicalWork, Sound Recording or Release in a LicenseAgreement.

Note: In many cases a Licensor is also the RightsController.

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.

Non-repudiation

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

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.

Right Share

A percentage or fraction of a right for a Musical Work for a particular time and place in which a party claims a controlling interest. Note: controlling interest includes ownership and/or administration.

 

 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 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 ddexC 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 this Standard have the mwl-ca-c namespace prefix.

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

http://ddex.net/xml/mwl-ca-c/11

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

In addition to including the baseline schemas, the schema file defined by this standard includes the schema files of to other DDEX standards: the Automated Message Exchange Protocol Standard and the Musical Works Licensing Message Suite Standard.

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.

6 Choreographies

 6.1 Introduction
This clause defines the method how a Licensee can provide a Sales Report to a Licensor who can, if needed reply with an Invoice. Both communications are performed via an FTP or SFTP server.

This specification does not define on whose hardware the files are being stored; this is for Licensor and Licensee to agree.

Security and non-repudiation issues are addressed as specified by DDEX’s Automated Message Exchange Protocol Standard.

 6.2 Licence Request

The choreography for requesting a licence, communicating supporting documentation is depicted in Figure 1.

 

Figure 1: Choreography: Licence Request

 

Licence requests for all Releases - including budget and products containing right shares subject to a controlled composition clause - are per product.

The same level of granularity applies to the licences granted (or not)

 

 

The LicenceOrClaimRequestMessage is defined in the latest version of DDEX’s Musical Works Licensing Message Suite Standard. The level of granularity for such licence requests is detailed in Clause 7.

The ContractDeliveryMessage is defined in Clause 9.3, a graphical representation is depicted in Figure 3. Note a ContractDeliveryMessage must be sent for each Licence Request for which a controlled composition rate is requested. The ContractDeliveryMessage may, if the relevant contract has already been sent, reference such contract by a unique ID.

The ManifestMessage is defined in Clause 9.4 a graphical representation is depicted in Figure 4.

The FtpAcknowledgementMessage is defined in the latest version of DDEX’s Automated Message Exchange Protocol Standard; a graphical representation is depicted below.

Figure 2: FtpAcknowledgementMessage

Figure 3: ContractDeliveryMessage

Figure 4: ManifestMessage

The FTP/SFTP server structure and file naming conventions are defined in Clauses 8.2 and 8.3 of this standard.

 6.3 Delivery of Resource Bit Stream Files
The delivery of the Resource bit stream files is effected as defined in Clause 8.3 (“FTP Batch Profile”) of DDEX’s ERN Choreography Standard with the NewReleaseMessage is defined in the latest version of DDEX’s Electronic Release Notification Message Suite Standard.

The Message Sender shall send two resource bit stream files, one containing the entire Sound Recording one containing an excerpt covering approximately 90 seconds. Information regarding these two Resource bit stream files shall be communicated through the TechnicalSoundRecordingDetails composite defined in the Electronic Release Notification Message Suite Standard.

 6.4 Request for a Licence Request
If a Licensor needs to request a licence request, or an updated licence request for a Release, the choreography depicted below shall be used.

The LicensingInformationRequestMessage is defined in DDEX’s Musical Works Licensing Message Suite Standard.

The ManifestMessage is defined in Clause 9.4 a graphical representation is depicted in Figure 4.

The FtpAcknowledgementMessage is defined in the latest version of DDEX’s Automated Message Exchange Protocol Standard; a graphical representation is depicted below.

The FTP/SFTP server structure and file naming conventions are defined in Clauses 8.2 and 8.3 of this standard.

 

Figure 5: Choreography: Requesting a Licence Request

 6.5 Licence Grant

The choreography for granting (or refusing) a licence and accepting (or rejecting) it, is depicted in Figure 6.

The LicenceOrClaimMessage and LicenceOrClaimConfirmationMessage are defined in the latest version of DDEX’s Musical Works Licensing Message Suite Standard. The level of granularity for such licence grants is detailed in Clause 7.

The ContractDeliveryMessage is defined in Clause 9.3, a graphical representation is depicted in Figure 3.

The ManifestMessage is defined in Clause 9.4 a graphical representation is depicted in Figure 4.

The FtpAcknowledgementMessage is defined in the latest version of DDEX’s Automated Message Exchange Protocol Standard; a graphical representation is depicted above.

The FTP/SFTP server structure and file naming conventions are defined in Clauses 8.2 and 8.3 of this standard.

 

Figure 6: Choreography: Licence Grant

If one of the right shares "contained" in a Release is subject to a controlled composition clause, the entire Release is handled as if all shares are subject to such clauses.

 

 6.6 Product Deletion
The choreography for informing a Licensee that a Product is no longer available and that there are no further royalties to be reported, is depicted in Figure 7.

 

Figure 7: Choreography: Product Deletion

The ProductDeletionMessage is defined in Clause 9.5, a graphical representation is depicted in Figure 3.

The ManifestMessage is defined in Clause 9.4 a graphical representation is depicted in Figure 4.

The FtpAcknowledgementMessage is defined in the latest version of DDEX’s Automated Message Exchange Protocol Standard; a graphical representation is depicted above.

The FTP/SFTP server structure and file naming conventions are defined in Clauses 8.2 and 8.3 of this standard.

 

Figure 8: ProductDeletionMessage

 6.7 Information on directly licensed Shares
The process of a Licensee to inform a Licensor about directly licensed shares follows the same process defined in Clause 6.5, albeit in reverse and limited to the top half. This is depicted below:

 

Figure 9: Choreography: Information on directly licensed Shares

The FTP/SFTP server structure and file naming conventions are defined in Clauses 8.2 and 8.3 of this standard.

7 Granularity of Licences and Right Shares

 

 7.1 Initial Licence Requests
Licence requests with the LicenceOrClaimRequestMessage are being made with respect to a (physical) product. This is an implicit request for a licence for all Right Shares on all MusicalWorks used on all Sound Recordings on that product.
 7.2 Initial Licence and Share Provision
Direct replies to such a licence requests shall provide all known Right Shares for all Musical Works used on all Sound Recordings on that product. For all unknown Right Shares for a Musical Work an “auxiliary” Right Share with owner “unknown” shall re communicated. For each Right Shares for which a licence can be provided, such Licence shall be communicated. Such communication shall make use of the LicenceOrClaimMessage.
 7.3 Normal Updates to Licence and Share Provision
Subsequent updates to that LicenceOrClaimMessage shall be on Musical Work level. That is when some information on one or more single Right Share(s) changes, or when a licence for such a Right Share changes, all Right Shares (and, where available, licences for such Right Shares) shall be updated.

It is the responsibility of the recipient of the LicenceOrClaimMessage to apply the changes to all affected Sound Recordings and/or products (i.e. all Sound Recordings and/or products that make use of the updated Work).

 7.4 Exceptional Updates to Licence and Share Provision
Should changes to a product affect more than a single Musical Work (e.g. when a new Musical Work is identified to have been used in a specific Sound Recording), a complete set of all LicenceOrClaimMessages for all affected products shall be sent.

For the avoidance of doubt, should, there be changes to several Musical Works in a single Sound Recording, the process defined in Clause 7.3 still applies.

8 Server Organisation

 8.1 Batch Definition
A Batch may contain any number and any kind of message. So, a Batch sent from a Licensee to a Licensor may contain:
  • LicenseOrClaimRequestMessages;
  • ContractDeliveryMessage (including referenced PDF versions of the contract);
  • LicenceOrClaimConfirmationMessages;
  • LicenceOrClaimMessages (to inform Licensors about directly licensed shares);
  • ProductDeletionMessages;
  • ManifestMessages; and
  • FtpAcknowledgementMessages.

Note that the communication of Resource bit streams is effected using the protocol defined in DDEX-ECHO and is, thus, not detailed herein.

Conversely, a Batch sent from a Licensor to a Licensee may contain:

  • LicenceOrClaimMessages;
  • LicenseOrClaimRequestRequestMessages;
  • ManifestMessages; and
  • FtpAcknowledgementMessages.

A batch is “closed” when the sender of the Batch has uploaded a ManifestMessage referencing all messages and files contained therein. At that stage the Batch is ready to be downloaded by the receiving party.

The trigger to “close” a batch is not defined by this standard.

The sender of the batch may remove a Batch and all messages and files contained therein when it has successfully downloaded the FtpAcknowledgeMessage for the Batch.

It is not permitted to include a licence for the same Release/product into a single Batch more than once.

It is not permitted to include a licence request for the same Release/product into a single Batch more than once.

 8.2 FTP/SFTP Server Organisation
Each Batch shall be placed into a separate folder of its own. To ensure sequential processing, a Batch is identified by a BatchId comprising:
Sender_Recient_YYYYMMDDhhmmssnnn

With

  • Sender being the DDEX Party ID of the party compiling the Batch;
  • Recipient being the DDEX Party ID of the party for whom the Batch is compiled; and
  • YYYYMMDDhhmmssnnn being a sequence with YYYY indicating the year in which the batch is created on the FTP/SFTP server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicates the millisecond in which the Batch is placed on the FTP/SFTP server.

 

The party sending the Batch shall make sure that for each of its partners that the BatchId is unique.

The folder shall be named with the ReleaseId of the Release communicated followed by an underscore character and the date/time of creation in the form YYYYMMDDhhmmssnnn to indicate a sequence with YYYY indicating the year in which the Release is placed on the FTP/SFTP server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicate the millisecond in which the Release is placed on the FTP/SFTP server.

 8.3 File Naming Convention

8.3.1 Messages

The messages other than manifests and acknowledgements communicated in the context of the Canadian Mechanical Licensing Choreography, shall be named according the following naming convention:

MessageType_ReleaseId_YYYYMMDDhhmmssnnn.xml

With

  • MessageTypebeing the an indicator for the type of message being communicated in the form of the top level tag of the XML file containing the message with the exception of:
    • Manifest” standing for a ManifestMessage; and
    • ACK” standing for an FtpAcknowledgementMessage.
  • ReleaseId being the identifier that uniquely identifies the Product. This is typically the UPC for the product; and
  • YYYYMMDDhhmmssnnn being a sequence with YYYY indicating the year in which the message is placed on the FTP/SFTP server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicates the millisecond in which the Release is placed on the FTP/SFTP server.

8.3.2 Manifests and Acknowledgements

Manifests and acknowledgements communicated in the context of the Canadian Mechanical Licensing Choreography, shall be named according the following naming convention:

MessageType _YYYYMMDDhhmmssnnn.xml

With

  • MessageType being either “Manifest” or “ACK”; and
  • YYYYMMDDhhmmssnnn being a sequence with YYYY indicating the year in which the message is placed on the FTP/SFTP server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicates the millisecond in which the Release is placed on the FTP/SFTP server

8.3.4 Contracts

The PDF files representing contracts shall be names according to the following file naming convention:

Contract_ContractID_YYYYMMDDhhmmssnnn.pdf

With:

  • ContractID being a unique ID for the contract as allocated by the sender of the ContractDeliveryMessage;
  • YYYYMMDDhhmmssnnn being a sequence with YYYY indicating the year in which the PDF file of the contract is placed on the FTP/SFTP server while MM and DD indicate the month and day, hhmmss indicate the hour (in 24 hours), minutes and seconds. Finally nnn indicates the millisecond in which the Contract is placed on the FTP/SFTP server.

 

 8.4 Example of a Batch (informative)
The table below shows a Batch containing two licence requests for product identified with UPC 010203040 and 101918171, including a contract delivery for one of the two licence requests.

The batch is send from PA-DPID-1234567890-A to PA-DPID-0987654321-Z. Folders are indicated by a trailing slash (“/”). Files in black are uploaded by the Batch sender, files in red are uploaded by the Message Recipient.

PADPID1234567890A_ PADPID0987654321Z_20110509131500000/

     LicenceOrClaimRequestMessage_010203040_20110509132000000.xml

     ContractDeliveryMessage__010203040_20110509132000000.xml

     Contract_1A.pdf

     Manifest_201105091330000000

     ACK_20110601125200000.xml

Figure 10: Example of a Batch

Note that the existence of the acknowledgement (ACK_20110601125200000.xml) does not constitute a licence; it solely indicates that the recipient of the batch – here a Works Licensor – has received the Batch.

9 Message Definition

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

 9.2 General Conformance Rules

9.2.1 Schema Validation

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

9.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 A – 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.

9.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 MessageRecipient.

9.2.4 Schema Version ID

For messages defined directly herein the only valid value for this field is

mwl-ca-c/11

For messages defined in DDEX’s Automated Message Exchange Protocol Standard, the relevant value of that standard shall be used.

For messages defined in DDEX Electronic Release Notification Message Suite Standard, the relevant value of that standard shall be used.

For messages defined in DDEX’s Musical Works Licensing Message Suite Standard, the relevant value of that standard shall be used.

 9.3 ContractDeliveryMessage

ContractDeliveryMessage

A Message in the Choreography for the Mechanical Licensing of Musical Works in Canada that is sent to inform about a contract delivery.

Message Element

Data Type

Card

Element Description

MessageVersionId

String

1

The Version of the Message.

MessageHeader

ddexC:MessageHeader

1

The MessageHeader for the mwl-ca-ContractDeliveryMessage.

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the MessageHeader 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.

 

MessageThreadId

String

1

A string used to uniquely identify the thread of Messages of which the current Message is a part. One example of such a 'thread' is the chain of NewReleaseMessages being sent from ReleaseCreator to wholesale ReleaseDistributor 1 to retail DSP when communicating information about the same Release(s). A common MessageThreadId will allow all these messages to be tied together.

 

MessageId

String

1

A string used to uniquely identify the current Message.

 

MessageFileName

String

0-1

The FileName, possibly including the FilePath, of the XML File containing the current Message.

 

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.

 

SentOnBehalfOf

ddexC:MessagingParty

0-1

A Composite containing details of the Party on whose behalf the Message is sent.

 

 

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

 

MessageAuditTrail

ddexC:MessageAuditTrail

0-1

A Composite containing information about Parties in between the original MessageSender and ultimate MessageRecipient.

 

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the MessageAuditTrail 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.

 

 

MessageAuditTrailEvent

ddexC:MessageAuditTrailEvent

1-n

A Composite containing details of a Party handling the Message and the Time at which the handling took place.

 

 

 

MessagingPartyDescriptor

ddexC:MessagingParty

1

A Composite containing details of a MessagingParty.

 

 

 

 

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.

 

 

 

DateTime

DateTime

1

The DateTime at which the Message was handled by the MessagingParty (the only allowed format is ISO 8601:2004: YYYY-MM-DDThh:mm:ssTZD).

 

Comment

ddexC:Comment

0-1

A Composite containing a human-readable Comment about the Message.

 

 

LanguageAndScriptCode

String

0-1

The Language and script of the Comment 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.

 

MessageControlType

MessageControlType

0-1

The indicator used to distinguish a live Message from a test Message.

LicenseOrClaimRequestId

ddexC:ProprietaryId

0-n

A Composite containing details of an Identifier of the License or Claim request that is being cancelled.

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

LicenseOrClaimId

ddexC:RightsAgreementId

0-n

A Composite containing details of Identifiers of a License or Claim for the MusicalWork.

 

MWLI

String

0-n

A MusicalWork License Identifier identifying a License. If the Composite is meant to describe a Claim, RightShare or contract, then the License relates to that Claim, RightShare or contract. A MWLI comprises four parts: one of the strings "M1" or "M2" or "M3" or "M4", followed by five alphanumeric characters, ten alphanumeric characters and one alphanumeric check character.

 

ProprietaryId

ddexC:ProprietaryId

0-n

A Composite containing details of a ProprietaryIdentifier of the License, Claim, RightShare or contract.

 

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

XmlChoice

 

1

An XmlComposite corresponding to the xs:choice element in an XML document or schema.

A

ReferencedContractID

ddexC:ProprietaryId

1

A Composite containing details of an Identifier of a previously sent contract.

 

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

B

URL

String

1

A URL of the PDF File of the contract.

B

ContractID

ddexC:ProprietaryId

1

A Composite containing details of the Identifier of the contract sent in this Message, for future reference.

 

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

 9.4 ManifestMessage

ManifestMessage

A Message in the Choreography for the Mechanical Licensing of Musical Works in Canada that is sent to document the FTP/SFTP transfer of a batch of Release Notification Messages, potentially accompanied by Resource or Release files.

Message Element

Data Type

Card

Element Description

MessageVersionId

String

1

The Version of the Message.

MessageHeader

amep:FtpMessageHeader

1

The MessageHeader for the mwl-ca-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).

MessageNotificationPeriod

ddexC:MessageNotificationPeriod

1

A Composite containing details of a reporting Period covered by the Messages. It must contain at least one out of StartDate or EndDate. The StartDate must be earlier than the EndDate if both are provided.

 

StartDate

Date

1

The Date that marks the beginning of the Period (in ISO 8601:2004 format: YYYY-MM-DD). This cannot be a Date in the future.

 

EndDate

Date

1

The Date that marks the end of the Period (in ISO 8601:2004 format: YYYY-MM-DD). This cannot be a Date in the future.

NumberOfMessages

Integer

1

The number of Messages in the batch communicated through the mwl-ca-ManifestMessage.

MessageInBatch

mwl-ca-c:MessageInBatch

1-n

A Composite containing details of a Message in the batch.

 

MessageType

MwlCaCMessageInBatchType

1

The Type of Message.

 

MessageId

String

1

An Identifier of the Message.

 

URL

String

1

A URL of the Message.

 

XmlChoice

 

0-1

An XmlComposite corresponding to the xs:choice element in an XML document or schema.

 

A

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.

 

B

Signature

ftpx/amep:Signature (ds:Signature)

1

A digital signature in accordance with DDEX-DSIG.

 9.5 ProductDeletionMessage

ProductDeletionMessage

A Message in the Choreography for the Mechanical Licensing of Musical Works in Canada that is sent to inform about a Product deletion.

Message Element

Data Type

Card

Element Description

MessageVersionId

String

1

The Version of the Message.

MessageHeader

ddexC:MessageHeader

1

The MessageHeader for the mwl-ca-ContractDeliveryMessage.

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the MessageHeader 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.

 

MessageThreadId

String

1

A string used to uniquely identify the thread of Messages of which the current Message is a part. One example of such a 'thread' is the chain of NewReleaseMessages being sent from ReleaseCreator to wholesale ReleaseDistributor 1 to retail DSP when communicating information about the same Release(s). A common MessageThreadId will allow all these messages to be tied together.

 

MessageId

String

1

A string used to uniquely identify the current Message.

 

MessageFileName

String

0-1

The FileName, possibly including the FilePath, of the XML File containing the current Message.

 

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.

 

SentOnBehalfOf

ddexC:MessagingParty

0-1

A Composite containing details of the Party on whose behalf the Message is sent.

 

 

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

 

MessageAuditTrail

ddexC:MessageAuditTrail

0-1

A Composite containing information about Parties in between the original MessageSender and ultimate MessageRecipient.

 

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the MessageAuditTrail 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.

 

 

MessageAuditTrailEvent

ddexC:MessageAuditTrailEvent

1-n

A Composite containing details of a Party handling the Message and the Time at which the handling took place.

 

 

 

MessagingPartyDescriptor

ddexC:MessagingParty

1

A Composite containing details of a MessagingParty.

 

 

 

 

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.

 

 

 

DateTime

DateTime

1

The DateTime at which the Message was handled by the MessagingParty (the only allowed format is ISO 8601:2004: YYYY-MM-DDThh:mm:ssTZD).

 

Comment

ddexC:Comment

0-1

A Composite containing a human-readable Comment about the Message.

 

 

LanguageAndScriptCode

String

0-1

The Language and script of the Comment 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.

 

MessageControlType

MessageControlType

0-1

The indicator used to distinguish a live Message from a test Message.

DeletedReleaseDeal

mwl-ca-c:DeletedReleaseDeal

1-n

A Composite containing details of one or more Deals pertaining to one or more Releases that are no longer available and for which no royalties are to be distributed.

 

ReleaseSummary

ddexC:ReleaseSummary

1-n

A Composite containing summary details of a Release to which the Deal(s) apply.

 

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the ReleaseSummary 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.

 

 

ReleaseId

ddexC:ReleaseId

1-n

A Composite containing details of ReleaseIds. If available, a GRid shall always to be used. If the Release contains only one SoundRecording, the ISRC of the SoundRecording may be used instead. If the Release is an abstraction of a complete PhysicalProduct (such as a CD Album), the ICPN of the PhysicalProduct may be used instead. More than one of these identifiers may be provided.

 

 

 

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.

 

 

ReferenceTitle

ddexC:ReferenceTitle

1

A Composite containing details of the ReferenceTitle of the Release.

 

 

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the ReferenceTitle 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.

 

 

 

TitleText

ddexC:TitleText

1

A Composite containing the text of the ReferenceTitle.

 

 

 

 

LanguageAndScriptCode

String

0-1

The Language and script of the TitleText 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.

 

 

 

SubTitle

ddexC:SubTitle

0-1

A Composite containing details of a SubTitle of the ReferenceTitle, including Titles of Versions used to differentiate different versions of the same Title, as required by the GRid and ISRC ReferenceDescriptiveMetadataSets (where the SubTitle is called Version Title).

 

 

 

 

LanguageAndScriptCode

String

0-1

The Language and script of the SubTitle 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.

 

 

ReleaseSummaryDetailsByTerritory

ddexC:ReleaseSummaryDetailsByTerritory

0-n

A Composite containing summary details of Descriptors and other attributes of the Release which may vary according to Territory of Release. Territory of Release may be the world.

 

 

 

LanguageAndScriptCode

String

0-1

The Language and script for the Elements of the ReleaseSummaryDetailsByTerritory 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.

 

 

 

XmlChoice

 

1

An XmlComposite corresponding to the xs:choice element in an XML document or schema.

 

 

 

 

TerritoryCode

ddexC:TerritoryCode

1-n

A Territory to which the ReleaseSummaryDetailsByTerritory apply (represented by an ISO 3166-1 TerritoryCode). Either this Element or ExcludedTerritory shall be present, but not both.

 

 

 

 

ExcludedTerritoryCode

ddexC:TerritoryCode

1-n

A Territory to which the ReleaseSummaryDetailsByTerritory do not apply (represented by an ISO 3166-1 TerritoryCode). Either this Element or Territory shall be present, but not both.

 

 

 

DisplayArtistName

ddexC:Name

0-n

A Composite containing the Name to be used by a DSP when presenting Artist details of the Release to a Consumer.

 

 

 

 

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.

 

 

 

LabelName

ddexC:LabelName

0-n

A Composite containing the Name of the Label for the Release.

 

 

 

 

LanguageAndScriptCode

String

0-1

The Language and script of the LabelName 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.

 

 

 

 

LabelNameType

String

0-1

A Type of LabelName. This is represented in an XML schema as an XML Attribute.

 

 

 

RightsAgreementId

ddexC:RightsAgreementId

0-1

A Composite containing details of Identifiers of a License, Claim, RightShare or contract for the MusicalWork(s) used in the Release.

 

 

 

 

MWLI

String

0-n

A MusicalWork License Identifier identifying a License. If the Composite is meant to describe a Claim, RightShare or contract, then the License relates to that Claim, RightShare or contract. A MWLI comprises four parts: one of the strings "M1" or "M2" or "M3" or "M4", followed by five alphanumeric characters, ten alphanumeric characters and one alphanumeric check character.

 

 

 

 

ProprietaryId

ddexC:ProprietaryId

0-n

A Composite containing details of a ProprietaryIdentifier of the License, Claim, RightShare or contract.

 

 

 

 

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

 

 

RightsAgreementId

ddexC:RightsAgreementId

0-1

A Composite containing details of Identifiers of a License, Claim, RightShare or contract for the MusicalWork(s) used in the Release.

 

 

 

MWLI

String

0-n

A MusicalWork License Identifier identifying a License. If the Composite is meant to describe a Claim, RightShare or contract, then the License relates to that Claim, RightShare or contract. A MWLI comprises four parts: one of the strings "M1" or "M2" or "M3" or "M4", followed by five alphanumeric characters, ten alphanumeric characters and one alphanumeric check character.

 

 

 

ProprietaryId

ddexC:ProprietaryId

0-n

A Composite containing details of a ProprietaryIdentifier of the License, Claim, RightShare or contract.

 

 

 

 

Namespace

String

1

The Namespace of the ProprietaryId. This is represented in an XML schema as an XML Attribute.

 

ReleaseDeletionDate

String

1

The Date at which the Release(s) became or will become unavailable.

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…