6.1 Introduction

This Clause contains an overview for each of the two messages in the Musical Work and Share Notification Choreography Standard in a tabular form. The full technical specification is includes the XML Schema files accompanying this standard.

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

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

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

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

The syntax as well as the semantics of the various elements in the messages is provided in this clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.This Clause contains an overview for each of the two messages in the Musical Work Share Notification Choreography Standard in a tabular form. The full technical specification is included in the XML Schema files accompanying this standard.

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

Other possible cardinality entries are:

  • "1" for exactly one;

  • "0-1" for none or one; or

  • "0-n" for none to multiple.

Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the message sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages. Instead exactly one of the “branches” below the XmlChoice keyword has to be used.

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

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

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