6.1 Introduction

This Clause contains an overview for each of the messages in the Recording Data and Rights Notification standard. The full technical specification is provided in the XML Schema files accompanying this standard.

The standard comprises nine messages: 

  • DeclarationOfSoundRecordingRightsClaimMessage - A message in the Recording Data and Rights Notification Standard containing details of a Resource.

  • RightsClaimStatusUpdateMessage - A message in the Recording Data and Rights Notification Standard that enables the updating of a RightsClaim status.

  • RevokeSoundRecordingRightsClaimMessage - A message in the Recording Data and Rights Notification Standard in which a claim, typically communicated via a DeclarationOfSoundRecordingRightsClaimMessage, is revoked.

  • RequestSoundRecordingRightsClaimMessage - A message in the Recording Data and Rights Notification Standard containing a request for a declaration of Resources.

  • AssertionOfCollectionMandateMessage - A message in the Recording Data and Rights Notification Standard containing details of an Assertion of a collection Mandate.

  • AssertionOfCollectionMandateStatusUpdateMessage - A message in the Recording Data and Rights Notification Standard containing details of a status update of an Assertion of a collection Mandate.

  • RevokeCollectionMandateMessage - A message in the Recording Data and Rights Notification Standard containing details of a revocation of a prior Assertion of a collection Mandate.

  • SalesReportMessage - A message in the Recording Data and Rights Notification Standard used by one Music Licensing Company to inform a second Music Licensing Company about unit sales of Resources in electronic or physical formats.

  • DeclarationOfRevenueMessage - A message in the Recording Data and Rights Notification Standard containing a declaration of Revenue from the usage of Resources. 

The hierarchical structure of the messages is provided through indentation. In the message header for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName and a PartyId. A second example from the message header is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a DateTime element. All elements that have subelements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the message summary, the cardinality. In the case of MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more MessageAuditTrailEvents. Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for: none or one) or "0-n" (for: none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages. Instead exactly one of the “branches” below the XmlChoice keyword has to be used. Each branch is indicated by a capital letter A, B, C, ... Each branch may consist of several sub-elements.

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

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

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

Search