Technical Document Formats
As part of our aim to deliver a simpler and more effective global content supply chain, we publish a range of technical documents. This page describes the formats we use. Or, you can browse the documents.
A DPP Recommendation is a normative document that defines specific technical parameters. It sets out to meet a defined set of business requirements with a technical solution. Implementers of a DPP Recommendation are expected to implement it in full.
DPP Guidance documents are informative, offering supporting information, guidelines, or suggested implementation parameters. They may include technical details, but they are usually suggestions rather than requirements. Implementers of a DPP Guidance document are free to choose which elements to implement.
DPP Business Requirements documents outline a set of business requirements, collected from our member companies and/or the wider industry. They are most likely to be published before work begins on a Recommendation or Guidance document, as they set the framework of requirements that subsequent document(s) will fulfil.
DPP Delivery Requirements are template documents which can be used by content providers that commission content, to define their own delivery requirements. They are designed in line with DPP Recommendations or specifications such as AMWA AS-11 and SMPTE TSP 2121.
Governance
DPP documents using the above formats undergo a formal governance and approval process. The process begins with a Project Group made up of interested DPP members, who work on the document. This is followed by a review process involving a broader group of interested DPP members.
The Project Group will have a Chair (usually a volunteer from a DPP member company) and a DPP Project Lead (usually a Programme Delivery Manager from the DPP staff). Wider reviews are conducted by the DPP Tech Network.
The review process is as follows:
- The Project Group prepares a draft.
- The Project Group Chair and DPP Project Lead review the document and agree when to submit the document for wider review.
- The draft document is sent to the DPP Tech Network mailing list, and, where relevant, discussed at the quarterly DPP Tech Network meeting.
- Two weeks are allowed for DPP members to review the document. Comments are submitted to the Project Group Chair and DPP Project Lead.
- Where necessary, the Project Group Chair and DPP Project Lead will make minor changes to the document based on the comments.
- If any of the feedback received is significant enough to require a redraft of the document, the process begins again.
- If no substantive changes are required, the Project Group Chair and DPP Project Lead propose the final document to the DPP Head of Delivery and Growth for approval and publication.
Versioning
We use simple version numbers for our documents, of the form:
majorVersion.minorVersion(.fixVersion)
The components are:
- majorVersion - a significant update, with major new functionality or changes. Backwards compatibility is always an aim, but is not guaranteed.
- minorVersion - a smaller update, with some new features or changes. Backwards compatible with all other minor versions of the same major version.
- fixVersion - a change that does not involve any technical change, and would not require any updates from implementers. May include things like fixing typos.
Partner Published Documents
In addition to DPP documents, some of our specifications are published in partnership with organisations such as:
