DCPD: Introduction

For additional DCPD information, see

  1. Introduction
  2. Framework
  3. Envelope
  4. Extensions
  5. Common Formats


Several years ago I thought long and hard about a computer file format to represent chess problems. It didn’t end up in anything close to what a file format specification needed to be, and I more or less abandoned the attempt when the task eventually proved to be too big.

In this series of posts I’m hoping to return to a subset of that task, focussed on preservation of pre-1900 problems, and split up into subtasks (or at least allow such subtasks to be created). This removes the entire field of modern unorthodox chess pieces, boards and rules from immediate consideration, although it retains historical chess pieces, rules and stipulations.

The general design principles of that first attempt were something on the following lines:

  • Use already existing standards when possible.

  • Design for information interchange (involving some form of publication concept).

  • Legibility to humans and ease of implementation is not very important.

  • In data, all alphabets have equal value

  • van der Poel’s principle applies (have either 0, 1, or an infinite number of anything).

  • define mechanisms, not policies

They still seem worthwhile today.

The “design language” that will be used is closely related to JSON, and it may be possible to create a JSON format from it. The main purpose, however, is to represent design structures without using special development tools or graphics for the job, and instead using textual descriptions. Creating a actual JSON or XML or … whatever format is another task, and won’t be considered here. Probably.

If you know JSON, you will probably be able to understand the design language without any major problems. The main differences are:

  • names in name-value pairs don’t have quotes

  • consecutive name-value entries are usually not separated by “,”.

  • comments are indicated by --, after which req and opt indicate if the field is required or optional.

  • ... (three periods) indicate omitted stuff. It is often things I haven’t thought about in any great detail, or that is detailed elsewhere.

As this is a design language format, file structures. character sets and end-of-line conventions do not really enter the picture. Those are part of realization or implementation phases.

The abbreviation ‘DCPD’ will be used to refer to this design format.

The next post is about the framework.