For additional DCPD information, see:
The format design structure is a smörgåsbord design: it provides building blocks for the eventual file format creator, and also an architecture for anyone needing to create new building blocks.
One format designer may only be interested in creating a chess problem bibliography. Files on this format would probably only contain bibliographical references and descriptions of problem books.
Another designer may want to create something like Gaige’s Chess Personalia, but in electronic form: biographic information about chess problem composers, judges, critics and other layabouts. (There is already something along those lines at https://database.wfcc.ch/ )
Yet another (such as me) may want to create a list of historical problem tourneys, and also to use the previous two file types for name and source details.
There are people who want to preserve existing card collections in a format that can be used for ease of duplication or processing.
And there are people who would like to copy all problem information (not only Forsyth position, but stipulation, name, awards, solutions and full bibliograph reference) from newsgroups, forums, PDF documents, etc.
And of course many want all problems in Illustrated London Times, Boston Weekly Globe, … etc. into their personal databases for reference and possibly research.
Each of those areas of application, along with many other, will need one or more file formats for storage or publication. The goal for the design is to provide some of the building blocks needed for that work.
There is no intention to create a design for a ‘one size fits everybody’ format.
The focus on interchange (and thus based on some degree of publication) makes this more of a .pdf format than a .docx or .odt format, if I may use a simile from document production. Or .png format rather than .pspimage format, to use computer graphics files as metaphor. Or perhaps .html format instead of .md format for anyone who is more familar with web production.
Building block design typically need some way of ensuring clean name spaces. In this case, field names starting with ‘dcpd:’ identify reserved names. (Any particular realization may decide if and how this is expressed in that realization.)
The next post in this series describes the envelope, shared by all format designs based on the DCPD idea.