Candidate Standard

Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains the Standard for Version 1.0.1 of the Communication of Media Enrichment and Description Information (MEAD).

Essential Reading

Download Standard (PDF) 

Tabular representation of the MEAD Standard (XLS)

Download XML Schema Definition Files (ZIP)

 The DDEX Data Dictionary ...

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

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

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

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

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

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

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

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

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

... for Work and Share Notifications

... for Works Licensing

Why are there multiple data dictionaries?

1 Introduction

One main part of the music industry supply chain is the delivery of Resource, Release and product information from Release Creators – typically record companies – to Release Distributors – typically DSPs. This information flow can happen either direct or via intermediaries and DDEX has developed a series of standards for this: The Electronic Release Notification Message Suite Standard (ERN), supported by a series of choreography and profile standards. ERN has been designed to convey the essential information about the Releases, Resources, involved parties as well as the commercial terms and conditions under which such Releases and Resources can be made available.

To offer a rich user experience, especially for instance, to support voice-activated music discovery and playback, DSPs require rich information which would not normally appear in current ERN formatted messages even though some of it might be available at the record company. However, DSPs may also obtain such information from other sources, herein called Metadata Providers, and this standard defines the means by which a DSP can obtain such information as part of an ERN feed, a separate FTP-communicated message or via web services. 

Any organisation wishing to implement this (or any other DDEX Standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.

 

2 Scope

 2.1 Introduction
This standard defines a uniform way to for Metadata Providers (including Release Creators) to communicate rich information about Works, Resources, Releases and Parties (such as writers, recording artists, studio personnel, labels and others) to Release Distributors and other companies.

This first version of the Media Enrichment and Description standard focuses on the communication of such information from record companies to Release Distributors in a "feed" accompanying the communication of Release notifications using the ERN standard as well as bulk metadata feeds from metadata provider. 

 2.2 Organisation of the Document
This standard has eight clauses. The first four provide an introduction, scope, a list of normative references as well as abbreviations and definitions. 

Clause 6 then defines the choreographies for the Communication of Media Enrichment and Description Information before Clause 7 details the web service calls for such communications. Finally, Clause 8 provides the syntax of the messages defined in this standard.

 2.3 Release Notes
Version 1.0.1 corrects an error with the ##other element at the end of the MeadMessage. The XSD for Version 1.0 did not allow the use of an XSD for any additional tags that a Message Sender may wish to included into the message; this has now been corrected.

3 Normative References

 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. DDEX Data Dictionary Standard. Latest Version
  • DDEX. Electronic Release Notification Standard. Version 4 or later.
  • IETF. RfC 2616. Hypertext Transfer Protocol (HTTP/1.1). 1999
  • IETF. RfC 5023. The Atom Publishing Protocol. October 2007
  • IETF. RfC 6797. HTTP Strict Transport Security (HSTS). November 2012
  • IETF. RfC 2026. SSH File Transfer Protocol. October 2001
  • W3C: XML Schema Part 1: Structures. Second Edition. 2004
  • W3C: XML Schema Part 2: Data types. Second Edition. 2004

4 Terms and Definitions

 4 Terms and Definitions

Atom

Formally, the Atom Syndication Format, is an XML language used for web service feeds. The Atom Publishing Protocol is a simple HTTP-based protocol for creating and updating web resources.

Metadata Provider

A company that provides, usually on request, information about Works, Resources, Releases or Parties other than the information communicated in a NewReleaseMessage defined in the ERN Standard.

Examples include record companies as well as dedicated metadata service companies.

Editorial Comment
The above new definition will need to be added to DDEX's canon of essential definitions. This will be done at publication of the standard.

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. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.

Release Creator

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

Typical Release Creators are record companies.

Release Distributor

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

Typical Release Distributors are DSPs.

Web Service

A modern set of web technologies that allow small pieces of information, typically in the form of XML files, to be exchanged. Augmented with FTP (or other file exchange mechanisms) they can be used to communicate Releases along the music supply chain.

Web Service Call

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

Web Service Response

The sending of an XML document in direct response to a Web Service Call, using HTTP or HTTPS.

For the avoidance of doubt: the appropriate response is always the message indicated in the appropriate Choreography.

5 Abbreviations

 5 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
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

6 Choreograophies

 6.1 Introduction
This standard defines three different choreographies by which a Release Distributor can obtain media enrichment and description information from a Metadata Provider.
  1. The media enrichment and description information can be provided in a separate XML document, containing one or more MeadMessages formed in accordance with Clause 8 of this standard that is attached to a NewReleaseMessage. This allows record companies who have information that goes beyond what can be communicated in the ERN message to communicate such information using the already-established mechanisms to exchange this information. 
  2. The MeadMessage can also be sent independently from a NewReleaseMessage using SFTP – whether from a record company or a third party Metadata Provider; and
  3. The media enrichment and description information can be exchanged using web services using a call-back architecture where a DSP would "subscribe" to a specific metadata feed using a web service call and the Metadata Provider would reply, once it has new information, with a web service call.

Details for these cases are defined in the following subclauses.

 6.2 Communicating a MeadMessage as part of an ERN Feed
Release Creators send ERN feeds to Release Distributors. As part of such a feed, one or more separate XML document(s) containing exactly one MeadMessage in accordance with Clause 8 of this standard, can be sent alongside a NewReleaseMessage.

DDEX has not defined a mechanism by which a  MeadMessage can be communicated alongside an ERN-3 message (which does not have a SupplementalDocumentList element). The preferred approach is to send the  MeadMessage as a Text Resource with a user-defined TextType of  MeadMessage.

The XML document containing the MeadMessage shall be treated in accordance with the relevant ERN Choreography as if it were a Resource file. It shall, however, be referenced in the SupplementalDocumentList composite in the NewReleaseMessage instead of in the TechnicalDetails composite. Any document referenced in the MeadMessage shall also be treated as if it were a Resource file to the NewReleaseMessage.

The information in each of the the MeadMessages shall only contain information relevant to the Releases, Resources, Works or Parties referenced in the NewReleaseMessage to which the MeadMessage is attached.

 

 

 

 

 

 6.3 Messaging Auxiliary Information Using SFTP

 

 6.3.1 Introduction
Should Metadata Providers and Release Distributors agree to use SFTP for this communication, the following two approaches can be used.
 6.3.2 File-by-File Delivery
If Metadata Provider and Release Distributor agree on a file-by-file delivery (akin to the "Release-by-Release Profile" defined in the ERN Choreography Standard for SFTP), each file containing a MeadRequestMessage shall be named as MEAD_Identifier_YYYYMMDDhhmmssnnn.xml with
  • Identifier being the identifier used in the MeadMessage to identify the entity that the message that provides additional information for (should the MeadMessage contain more than one entity, the identifier shall be the one identifying the main entity as determined by the sender of the MeadMessage); and
  • YYYYMMDDhhmmssnnn being the date and time that the Release is placed on the ftp server. 

For example MEAD_0000000114819103_20190504102412000.xml is a file containing auxiliary information sent on 4th May 2019 at 10:24:12.000 for the band Marillion (who have been allocated an ISNI of 0000 0001 1481 9103). 

Any additional documents referenced from the MeadMessage shall be placed into the same folder as the MeadMessage. It must be uploaded to the FTP server before the MeadMessage is uploaded.

The recipient of such a MeadMessage may acknowledge the receipt by placing a file containing an FtpAcknowledgementMessage in the same folder as the acknowledged message. The FtpAcknowledgementMessage shall be named as ACK_Identifier_YYYYMMDDhhmmssnnn.xml with the same naming convention as above.

 6.3.3 Batched Delivery
If Metadata Provider and Release Distributor agree on a batched delivery of MeadMessages, the Metadata Provider shall create a separate folder for each Batch. 

To ensure sequential processing, a Batch shall be named YYYYMMDDhhmmssnnn/ with YYYYMMDDhhmmssnnn being the date and time that the set of MeadMessages is placed on the SFTP server.

The maximum size of a Batch is not defined in this standard but shall be agreed by the Metadata Provider and the Release Distributor before using this Profile. It is not permitted to include information about the same entity more than once in a single Batch.

If the Metadata Provider wants to have several Batches “open” at the same time, it needs to ensure that no information about the same entity is contained in more than one Batch.

The maximum time a Batch may be kept “open” is a matter for the Metadata Provider and the Release Distributor to define in their commercial agreement.

The Metadata Provider shall make sure that the Batch folder name is unique for each Batch.

The trigger to indicate that a Batch is complete, a zero-byte semaphore file shall be placed into the Batch folder. The semaphore file shall be named  BatchComplete_YYYYMMDDhhmmssnnn .

Each file containing a  MeadMessage  shall be placed into such a batch folder, following the same file naming convention as defined in Clause 6.3.1 of this Standard.

Any additional documents referenced from the MeadMessage shall be placed into the same folder as the MeadMessage. It must be uploaded to the SFTP server before the batch is closed.

The recipient of such a Batch may acknowledge the receipt of each MeadMessage by placing a file containing an FtpAcknowledgementMessage into a sub-folder acknowledgements/ which is placed into the same folder as the MeadMessage. The FtpAcknowledgementMessage shall be named following the same file name convention as defined in  Clause 6.3.1  of this Standard.

 6.4 Call Back-based Web Service Choreography

 

 6.4.1 Introduction
The approach to MeadMessage deliveries defined in this clause is symmetric. Metadata Providers and Release Distributors will need to publish and maintain a web service. The diagram below shows a typical exchange enabled by this choreography:

 

This clause defines the minimum that a web service provider needs to publish in order to be conformant with this standard. Additional services may be added on top of the features of the standard. For instance, the call to subscribe to a feed is defined herein to only apply to cases where the query leads to a single result. When a query leads to multiple results, the standard calls for an error to be returned – an extended service might offer the means to handle multiple results in an automated fashion.Not shown in the above diagram is the ability to unsubscribe to a service.

Also not specifically shown is the ability to access documents that are referenced from the MeadMessage. However, the process is the same as depicted above.

 6.4.2 URLs
The approach to web service-based metadata deliveries is based on URLs that are set at the discretion of the company who publishes the web service to its business partners.

While it can be assumed that many URLs follow a common syntax, there is no compulsion to use this approach. Similarly it is not compulsory that all URLs from one company follow a common syntax.

All the Metadata Provider and Release Contributor need to do, is to agree the URLs for the subscribe and unsubscribe calls as well as the metadata delivery calls.

Wherever this standard mentions only the HTTP protocol, it is to be understood that HTTPS communications are also allowed.

 6.4.3 Personalising the Feed
Many Metadata Providers have different offerings for different sets of business partners. In such circumstances it is essential that the web server of a Metadata Provider knows who is calling one of its web services. The same applies for calls to a Release Distributor's web service. 

This can be done with or without formal authentication (see Clauses 6.4.4 and 6.4.5, respectively). The benefit of using formal authentication is that it also allows Metadata Providers and Release Distributors to secure their communication.

 6.4.4 Web Service Set-up and Authentication
This standard does not define an authentication mechanism for the web service-based communication between Metadata Provider and Release Distributor. Should the two parties require their communication to be authenticated, they are free to use any of the existing web-based authentication methods including, but not limited to, Basic Auth, HTTP Digest Authentication, HTTPS Client Authentication, OAUTH, etc.
 6.4.5 Identifying Release Distributors Without Authentication
Establishing the identity of the caller to the web service can also be accomplished without formal authentication (although in that case the provider of a web service cannot be certain that the caller is who it claims to be) by including, for instance, the DDEX Party Identifier (DPID) of the web service caller into the URL syntax.

 6.5 Atom-based Web Service Choreography
The approach to metadata deliveries defined in this clause is asymmetric. Only the Metadata Provider needs to publish and maintain a web service. The diagram below shows a typical exchange enabled by this choreography:

 

The provisions defined in Clauses 6.4.2, 6.4.3, 6.4.4 and 6.4.5 also apply to the Atom-based choreography with the exceptions that (i) Metadata Providers and Release Distributors need to agree the URLs for the subscribe and unsubscribe calls as well as the Atom request call, and (ii) that the Metadata Provider must make sure that the URLs placed in the responses to web service calls are (a) valid and (b) active.

Not shown in the above diagram is the ability to unsubscribe to a service.

Also not specifically shown is the ability to access documents that are referenced from the MeadMessage. However, the process is the same as depicted above.

7 Web Service Commands

 7.1 Subscription (GET SubscriptionId)
7.1.1    Purpose

This command can be used by a Release Distributor to request information about MeadMessages that are ready for that particular Release Distributor to receive from a Metadata Provider.

The Release Distributor will call, after appropriate authentication if needed, the web service address previously agreed between the Metadata Provider and the Release Distributor.

7.1.2    Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 200 (OK);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server); and
  • 500 (Internal server error)

Other standard HTTP status codes may be used on bilateral agreement between the Release Creator and the Release Distributor.

The web server shall also return to the calling web service client an Atom Feed document as defined in Clause 8.1.

 7.2 Unsubscription (POST SubscriptionId)

7.2.1 Purpose

This command can be used by a Release Distributor to unsubscribe from a feed that it has previously subscribed to. The syntax for this call is not prescribed . 

Below are two possible approaches (with base.url being the URL agreed between the Metadata Provider and the Release Distributor and xxx being the identifier for the subscription that the Metadata Provider returned as part of the subscription request).

Example 1
base.url/path?unsubscribe=xxx
Example 2
base.url/unsubscribe/xxx

7.2.2 Syntax of Reply

The web server shall return one of the following standard HTTP response codes with their standard HTTP response code semantics:

  • 200 (OK);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found); and
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

If the status code is 200, the Web server shall stop sending further updates for the item from which the Release Distributor has just unsubscribed.

Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.

 7.3 POST MeadMessage

7.3.1 Purpose

This command can be used by a Metadata Provider to provide information on an item that a Release Distributor has subscribed to. The document to be posted is an MeadMessage as defined as in Clause 8.

7.3.2 Syntax of Reply

The web server of theRelease Distributor shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 204 (The server successfully processed the request but is not returning any content);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found); and
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

Other standard HTTP status codes may be used on bilateral agreementbetween the Metadata Provider and the Release Distributor.

 7.4 GET Metadata Feed

7.41    Purpose

This command can be used by a Release Distributor to request information about metadata that is ready for that particular Release Distributor to receive from a Metadata Provider.

The Release Distributor will call, after appropriate authentication, if needed, the web service address previously agreed between the Metadata Provider and the Release Distributor.

7.4.2    Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 200 (OK);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

If the status is 200, the web server shall also return to the calling web service client an Atom feed document as defined in Clause 8.

Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.

 7.5 GET MeadMessage
7.5.1   Purpose

This command can be used by a Release Distributor to request an MeadMessage. The web service address for this call is the URL for the specific instance of the requested MeadMessage.

The Release Distributor would typically have received this URL from an entry composite in an Atom feed document.

7.5.2   Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 200 (OK);
  • 301 (Moved permanently);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.

If the status code is 200, the web server shall also return to the calling web service client an XML file containing a valid MeadMessage  as defined in Clause 8.

If the status code is 301, the web server shall also return to the calling web service client the correct URL.

 7.6 DELETE Metadata Details

7.6.1 Purpose

This command can be used by a Release Distributor to signal to the Metadata Provider, that the Release Distributor has ingested, but not necessarily processed a specific metadata item, including all referenced documents.

It therefore signals to the Metadata Provider, that the Release Distributor no longer needs to receive web service calls with respect to the said metadata item from the Metadata Provider. After receiving this call, a Metadata Provider is free to remove the associated entry from its Atom feed.

If, after removing the item from the queue and removing the associated entry from its Atom feed, the Metadata Provider is updating the information about the item again, the metadata should – subject to its bilateral agreement with the Release Distributor – create a new Atom feed/entry for the same entity.

The syntax for this call is not prescribed except.

7.6.2 Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 204 (The server successfully processed the request but is not returning any content);
  • 208 (Already reported);
  • 400 (Bad Request) – which in this case means that the URL does not lead to a valid metadata message (any more);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.

 

 7.7 GET SupportingDocument
7.7.1   Purpose

This command can be used by a Release Distributor to request a supporting document that has been referenced in an MeadMessage. The web service address for this call is the URL for the specific instance of the requested document as provided in the MeadMessage.

7.7.2   Syntax of Reply

The web server shall return one of the following standard HTTP status codes with their standard HTTP response code semantics:

  • 200 (OK);
  • 301 (Moved permanently);
  • 400 (Bad request);
  • 401 (Unauthorised);
  • 404 (Not found);
  • 500 (Internal server error); and
  • 503 (Service unavailable due to a temporary overloading or maintenance of the server).

Other standard HTTP status codes may be used on bilateral agreement between the Metadata Provider and the Release Distributor.

If the status code is 200, the web server shall also return to the calling web service client the supporting document.

If the status code is 301, the web server shall also return to the calling web service client the correct URL.

8 Syntax of XML Messages

 8.1 Atom Feed

8.1.1 Introduction

The Atom feeds shall have follow the syntax as defined in the relevant XML Schema Definition file.

The following Atom feed entry elements have these meanings:

Atom Feed entry ElementNewReleaseMessage Element
//entry/title

The title tag shall contain three pieces of information separated by a semicolon and a space character:

  • DPID of the message sender (without dashes);
  • Subscription ID; and
  • Date when the entry was added to the feed queue (in the ISO format yyyy-mm-dd).
//entry/SubscriptionIdThe identifier for the subscription as provided, by the Metadata Provider to the Release Distributor during the subscription process
//entry/Work/*Information about the main entity for which information is provided. Only one of these elements can be provided in on //entry.
//entry/Release/*
//entry/Resource/*
//entry/Party/*

Entries should be entered into the feed sequentially, that is the oldest entry should be at the top and the latest addition should be at the bottom. A Metadata Provider may, however, add and remove entries at its own discretion.

The number of entry composites in the Atom feed is not prescribed by this standard. The Metadata Provider publishing the web service may, however, want to set a maximum number in collaboration with its business partner(s).

The following link types can be communicated in the //feed/link/@rel attributes:

  • self – to provide the URL of the feed itself;
  • next – to provide the URL to the next feed "page" (in the case where there is more than one feed page available to the Release Distributor); and
  • previous – to provide the URL to the previous feed "page" (in the case where there is more than one feed page available to the Release Distributor).

The following link types can be communicated in the //feed/entry/link/@rel attributes:

  • alternate – to provide the URL for the GET MeadMessage method defined in Clause 7.5; and

  • delete – to provide the URL for the DELETE MeadMessage method defined in Clause 7.6.
 8.2 MeadMessage
The MeadMessage shall have follow the syntax as defined in the relevant XML Schema Definition file.

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.