International
Tables for
Crystallography
Volume G
Definition and exchange of crystallographic data
Edited by J. R. Hester and B. McMahon

International Tables for Crystallography (2026). Vol. G. Early view chapter

Section 1.1.4. The software developer

James R. Hestera and Brian McMahonb

aAustralian Nuclear Science and Technology Organisation, Locked Bag 2001, Kirrawee DC, NSW 2232, Australia, and bInternational Union of Crystallography, 5 Abbey Square, Chester CH1 2HU, UK.

1.1.4. The software developer

| top | pdf |

Programmers wishing to write software that handles crystallographic data in CIF format should begin with the discussion of general principles in Chapter 5.1[link] . They should also read the relevant format specification in Chapters 2.2[link] (CIF versions 1.1 and 2.0) and 2.3[link] (imgCIF/CBF).

1.1.4.1. Refinement or data processing packages

| top | pdf |

Many developers of crystallographic software are focused on data processing and analysis problems, and are interested in CIF only as an input/output channel for passing data to and from an application. They may find that one of the standard libraries discussed in Chapter 5.3[link] will provide all the support needed for this purpose. Otherwise, they may find it helpful to read the description of the CIF application programming interface (Chapter 5.2[link] ), either to use directly the reference implementation (although this is not optimized for performance), or to design their own API on similar principles.

Writing native code to output CIF data is relatively straightforward, since the programmer may choose the order in which data may be written, and has few layout constraints. Attention to the details of the format specification should ensure that syntactically correct CIFs are formed. The programmer must of course take care to ensure that the correct data names are used, and that their associated values conform to the restrictions detailed in the relevant dictionary. The dictionary listings in Part 4 should provide enough information for this, though the matching commentary chapter in Part 3 should also be read to ensure correct usage. If the programmer wishes to reduce the burden of conformance to dic­tionary attribute constraints, it is possible to write routines to validate directly against the dictionaries. In this case, an understanding of the DDL in which the relevant dictionary is written can be gained from Chapter 2.4[link] . To implement any dictionary methods written in the dictionary relational language (dREL), one should also read Chapter 2.5[link] .

If it is wished to archive in a CIF file some data that are not characterized by existing dictionary definitions, new data names may be created, provided they are differentiated from the existing definitions by use of a [local] or otherwise registered prefix, as discussed in Section 2.1.4.2[link] .

Handling input CIF data is more complex, because of the free-form layout and ordering of data in an input file. If a suitable library is not used, the programmer may wish to use a filter program to preprocess the input into a normalized presentation that is easier to write native code to handle. Some programs to do this are discussed in Chapter 5.4[link] .

1.1.4.2. General utility programs

| top | pdf |

Some developers may wish to write generic programs to reorder, validate or otherwise transform CIFs (e.g to convert to a different format). Such developers will need a detailed understanding of the relevant format specifications (Chapters 2.2[link] , 2.3[link] ) and might also benefit from studying how edge cases are handled, for example by the CIF API (Chapter 5.2[link] ). If the goal is to transform CIF data into another syntactic representation, Chapter 2.6[link] might also provide some useful ideas.

Developers of applications that validate against dictionaries, or transform data based on relationships in the dictionaries (e.g to separate or merge data values and their standard uncertainties, or to convert matrices into lists of their individual components) should understand the DDL specifications in Chapter 2.4[link] . They may also be interested in implementing relational methods expressed in the dREL language (Chapter 2.5[link] ).

1.1.4.3. System developer

| top | pdf |

In this context, a system developer is one who aims to provide an end-to-end workflow, with tools that can take full advantage of all existing CIF features. Such an ambitious programmer should read all the specification chapters of Part 2, and the introductory discussions of general principles in programming (Chapter 5.1[link] ), dictionary construction (Chapter 3.1[link] ) and dictionary maintenance (Chapter 4.1[link] ).

Plans to develop re-usable application programming interfaces or software libraries should be informed by consideration of the CIF API (Chapter 5.2[link] ) or existing libraries (Chapter 5.3[link] ). It may also be useful to read the other chapters in Part 5 to identify existing programs that may be incorporated into the developing pipeline, ported to a more convenient programming language, or that may provide ideas on end-user function and usability.








































to end of page
to top of page